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EXECUTIVE  SUMMARY 


To  exploit  the  current  revolution  in  simulations  technologies,  the  U.S.  Army  Research 
Laboratory  (ARL)  and  Canadian  Aviation  and  Electronics  (CAE)-Link  developed  an  interface 
that  allows  fire  support  command  and  control  tactical  equipment  to  interact  in  a  seamless  manner 
with  computer-generated  equipment  and  forces  on  the  synthetic  battlefield.  The  interface  was 
accomplished  using  communications  protocols  that  comply  with  the  requirements  outlined  in  the 
distributed  interactive  simulation  (DIS)  protocol  data  unit  (PDU)  standards  2.0.3. 

The  interface  is  a  software  program  that  operates  on  a  standard  “486”  personal  computer 
(PC).  Thus  far,  the  PC  interface  unit  (PIU)  has  been  used  to  establish  DIS  compatibility  for  the 
following  tactical  equipment:  the  forward  entry  device,  digital  message  device,  fire  direction  data 
manager,  and  the  lightweight  computer  unit  that  runs  the  fire  direction  system  software  of  the 
multiple  launch  rocket  system  (MLRS).  Additionally,  a  DIS-compatible  fire  control  panel  trainer 
for  both  the  MLRS  and  the  Army  tactical  missile  system  (ATACMS)  has  been  placed  on  the 
network. 

Scenarios  were  developed  to  demonstrate  and  evaluate  the  network.  A  DIS-compatible 
constructive  simulation  was  used  to  generate  the  synthetic  battlefield.  Computer-generated 
weapon  systems  and  soldier-in-the-loop  simulators  and  training  devices  populated  the  synthetic 
environment.  Targets  were  detected  by  sensors  in  the  simulation  and  fire  missions  were 
forwarded  to  command  centers,  where  they  were  processed  and  sent  to  firing  batteries  for 
execution.  Occasionally,  the  calls  for  fire  were  processed  and  executed  by  the  distributed  soldier- 
in-the-loop  simulators  and  training  devices.  In  these  instances,  fire  missions  were  sent  to  the 
battalion  fire  direction  data  manager  or  the  battery  fire  direction  system  (FDS),  where  operators 
processed  the  messages  and  forwarded  missions  to  the  MLRS  or  ATACMS  training  device. 

Thus,  automated  and  distributed  entities  operated  in  an  interactive  maimer  on  a  single  synthetic 
environment  linking  live,  virtual,  and  constructive  simulations. 

The  current  project  was  done  in  support  of  the  Depth  and  Simultaneous  Attack  (D&SA) 
Battle  Lab  and  their  requirement  to  eiqiand  the  use  of  simulations  to  (a)  streamline  training  and 
(b)  evaluate  materiel,  organizational,  and  doctrinal  alternatives  during  depth  and  simultaneous 
attack.  The  D&SA  Battle  Lab  is  developing  a  simulation  facility  that  contains  a  collection  of 
DIS-compatible  simulations,  simulators,  and  training  devices  that  will  provide  the  necessary 
infrastructure  to  conduct  mission-related  training  and  analysis  events.  The  Fort  Sill  Field 
Element  of  the  Human  Research  and  Engineering  Directorate,  ARL,  is  supporting  their  work 
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through  the  execution  of  a  comprehensive  research  program  focused  on  the  development  of 
procedures  to  conduct  “soldier-in-the-loop”  investigations  throughout  the  concept  development 
process  and  the  research,  development  and  acquisition  phase  of  the  materiel  acquisition  cycle. 
The  utility  of  this  work  is  its  ability  to  support  training,  research  and  development,  and 
warfighting  operations—allowing  questions  related  to  doctrine,  training,  leadership,  organizations, 
and  materiel  to  be  addressed  before  “metal  is  bent”  or  soldiers  are  deployed. 
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DEVELOPMENT  AND  ENGINEERING  OF  A  DISTRIBUTED 
INTERACTIVE  SIMULATION  SYSTEM 


INTRODUCTION 

The  U.S.  Army  Research  Laboratory  (ARL)  requested  Canadian  Aviation  and  Electronics 
(CAE)-Link  to  instrument  the  ARL  and  Depth  and  Simultaneous  Attack  (D&SA)  Battle  Lab 
with  fire  support  command  and  control  equipment  using  the  distributed  interactive  simulation 
(DIS)  protocols  on  a  local  area  network  (LAN)  to  simulate  realistic  battlefield  communications 
conditions  for  research  and  development  and  training.  Devices  that  have  been  integrated  into  this 
simulation  capability  include  the  CIMUL8™/SPECT8™/DISIP8™  simulation  system,  two  (2) 
forward  entry  devices  (FEDs),  a  lightweight  computer  unit  (LCU)  running  the  multiple  lavmch 
rocket  system  (MLRS)  battery  fire  direction  system  (FDS),  and  the  MLRS/Army  tactical  missile 
system  (MLRS/ATACMS)  fire  control  panel  trainer  (FCPT). 

The  integration  of  these  devices  onto  an  instrumented  LAN  will  permit  realistic  fire 
support  command  and  control  exercises  to  be  conducted  in  conjimction  with  the  target  acquisition 
fire  support  model  (TAFSM),  Janus,  or  any  other  simulation  system,  using  real  soldiers 
performing  tasks  in  the  laboratory  as  they  would  in  the  field.  It  will  also  allow  for  the  evaluation 
of  the  MLRS/ATACMS  FCPT.  With  the  eventual  installation  of  a  wide  area  network  (WAN), 
personnel  will  be  able  to  participate  in  DIS  exercises  with  participants  at  remote  locations. 

The  DIS  network  interface  developed  for  the  FEDs  and  the  FDS  represents  the  first  time 
that  real,  unmodified  battlefield  command  and  control  equipment  has  been  interfaced  to  the 
synthetic  environment  using  DIS  (see  Appendix  A  for  a  complete  list  of  acronyms). 


Requirement 

The  technical  requirements  for  the  project  have  been  changed  because  of  system  operation 
and  equipment  availability.  Initially,  the  project  had  the  following  technical  requirements: 

a.  Procure  the  desktop  MLRS/ATACMS  FCPT  and  CIMUL8™/SPECT8™/  DISIP8™. 

b.  Provide  a  DIS-compatible  interface  for  several  FEDs  and  an  LCU  (operating  the 
interim  fire  support  automation  system  [IFSAS]  software). 
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c.  Integrate  the  devices  on  a  common  DIS  LAN  that  ^vonld  eventually  be  connected  to 
the  defense  simiilation  internet  (DSI)  (see  Figure  1). 


Figure  1.  Netv^ork  configuration  for  ARL  and  D&SA  Battle  Lab. 


Initial  Design 

In  the  initial  design,  the  network  was  to  include  four  FEDs,  one  IFSAS,  and  the  fire 
support  automated  test  system  (FSATS).  During  the  interim  progress  review,  it  was  determined 
that  the  IFSAS  did  not  have  the  capability  to  communicate  with  an  MLRS  launcher  (represented 
on  the  network  by  the  FCPT).  To  demonstrate  a  fully  interactive  network,  the  IFSAS  software 
was  replaced  by  the  battery  FDS  software.  The  FDS  software  communicated  with  the  MLRS 
launcher  and  like  the  IFSAS,  executed  on  an  LCU.  In  addition,  the  number  of  FEDs  was  initially 
limited  to  two  since  only  two  FEDs  were  available  for  testing. 

It  was  initially  believed  that  information  sent  by  the  FEDs  and  the  FDS  could  be  accessed 
using  the  RS-232  port  on  a  personal  computer  (PC).  It  was  determined,  however,  that  the 
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software  running  on  the  LCU  and  FEDs  could  not  be  modified  to  transmit  messages  through  the 
RS-232  port  and  that  access  would  have  to  be  gained  either  through  the  radio  ports  or  the  wire 
interface. 

The  solution  to  this  problem  was  to  communicate  with  the  FEDs  and  FDS  using  a  modem 
connected  to  the  wire  interfaces  of  the  FEDs  and  FDS.  Since  the  devices  used  firequency  shift 
keying  (FSK),  a  commercial  off-the-shelf  (COTS)  modem  could  not  be  used.  The  Telos®  signal 
master  board  was  chosen  as  the  FSK  modem  for  the  PCs.  Since  the  disk  operating  system 
(DOS™)  version  was  just  becoming  available  and  the  board  was  not  yet  produced,  two  beta 
version  boards,  each  with  two  channels,  were  obtained. 


DIS  Requirements 

DIS  Protocol  Data  Unit  (PDU)  Standard 

Systems  on  the  ARL  and  D&S  A  Battle  Lab  network  are  required  to  be  DIS 
compatible.  DIS  protocol  data  unit  (PDU)  version  2.0.3  was  chosen  for  implementation  because 
of  its  widely  installed  base  (used  for  the  Warbreaker  demonstration  among  other  projects). 

Only  the  DIS  PDUs  required  to  simulate  the  integrated  system  were  implemented. 
DIS  PDUs  were  implemented  in  the  following  manner  for  the  integrated  system: 

1 .  Command  and  control  messages  are  communicated  using  transmitter  and  signal 
PDUs.  Receiver  PDUs  are  not  used  in  this  implementation. 

2.  Entity  state  PDUs  are  issued  on  behalf  of  the  entity  containing  or  controlling 
the  transmitting  device.  Articulated  parts  are  not  represented. 

3 .  Fire  and  detonation  information  associated  with  the  munition  fired  by  the 
MLRS/ATACMS  FCPT  is  communicated  using  the  fire  PDU  and  detonation  PDU.  In  addition, 
positional  information  and  movement  of  the  launcher  represented  by  the  FCPT  is  represented 
using  entity  state  PDUs. 

DIS  Communication  Architecture  Standard 

The  communication  architecture  for  DIS  (CADIS)  draft  standard  version  1.0  was 
chosen  for  use  with  this  interface.  Protocols  to  be  used  on  the  local  area  network  are 
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DIS  2.0.3 


Application,  presentation  &  session  layers: 


UDP/IP  (CADIS  1.0) 

Ethernet 

Ethernet 


Transport  &  network  layer: 
Data  link  layer: 

Physical  layer: 


DIS  Radio  Simnlation 

Simulation  of  the  actual  radios,  along  with  associated  jamming,  noise,  interference, 
and  so  forth,  is  not  represented  in  this  integrated  system.  It  is  assumed  that  the  devices  send  and 
receive  perfect  signals.  It  is  also  assumed  that  for  this  application,  all  devices  are  tuned  to  the 
same  radio  frequency. 

DIS  Entity  Information  for  Command  and  Control  Entities 

Entity  information  for  the  entities  associated  with  the  transmitter  are  issued  in 
accordance  with  the  DIS  PDU  2.0.3  standard.  The  FEDs  and  the  FDS  are  associated  with  either 
dismoimted  infantry  or  a  specific  vehicle.  The  MLRS/ATACMS  FCPT  is  associated  with  the 
MLRS  carrier  vehicle.  CIMUL8™  provides  entity  representation  for  those  entities  that  it  is 
simulating. 


The  FED  and  the  FDS  related  entities  do  not  maneuver  while  the  simulation  is 
running.  There  is  an  off-line  capability  to  “beam”  the  FED  and  FDS  entities  to  various  locations 
on  the  battlefield.  An  on-line  capability  to  beam  entities  is  also  available,  based  on  latitude- 
longitude  location. 

ENGINEERING  DESIGN 
Hardware  Design 

The  hardware  selected  for  the  DIS  interface  uses  80486  personal  computers  (PCs). 

PCs  were  selected  for  the  ARL  network  interfaces  since  the  FEDs  simplified  hand-held  terminal 
unit  (SHTU)  and  the  FDS  lightweight  computer  unit  (LCU)  are  both  PC-compatible  devices.  In 
addition,  the  PC  solution  represented  a  low  cost  approach  from  a  hardware  and  software 
development  perspective.  The  use  of  the  PCs  also  allowed  the  use  of  existing  Government- 
owned  software  produced  by  the  University  of  Central  Florida’s  (UCF)  Institute  for  simulation 
and  training  (1ST).  An  additional  PC  was  procured  to  host  1ST  data-logging  software  and  to 
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serve  as  a  spare.  The  hardware,  software,  and  Government-provided  equipment  required  to 
complete  this  project  are  described  in  Appendix  B. 

To  provide  the  interface  to  the  network  without  modifying  the  software  on  the  FEDs, 
FDS,  or  fire  direction  data  manager  (FDDM),  the  interface  used  the  two-wire  communications 
interface  for  communication  between  the  PC  interface  and  the  devices.  Since  the  command  and 
control  equipment  uses  FSK  in  its  communications,  it  was  necessary  for  our  interface  to  have  an 
FSK  modem  to  establish  lower  layer  communications.  The  text  messages  that  are  sent  between 
command  and  control  devices  were  then  sent  as  the  data  portion  of  a  signal  PDU  on  the  DIS 
network.  The  PC  interface  is  shown  m  Figure  2. 


IVo  Channels 
For  Commnnications 


FSK 

PC 

Ethernet 

Modem 

Memory 

LAN 

Board 

Area 

Board 

DlSPDUs 

UDP/IP/Ethernet 


DlS  Network 


Figure  2.  PC  interface  with  FSK  modem  board. 


In  addition  to  the  PC  interface  devices,  the  hardware  and  cables  required  to  activate  the 
LAN  were  procured.  Figme  3  shows  the  hardware  configuration  for  the  ARL  and  D4&SA  Battle 
Lab  network. 
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I 


1 


MLRS  Fire  Control  Panel 
Trainer  (FCPT) 

486  PC  Compatible 
OS-2 


Figure  3.  Network  hardware  configuration. 


Software  Design 

Software  delivered  with  this  system  included  COTS  software  purchased  for  use  with  the 
PCs  and  the  CAE-Link  developed  interface  software  (see  Appendix  B). 
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COTS  Software 


Hardware  drivers  purchased  with  the  Ethernet  board  and  the  modem  board  were 
used  as  part  of  the  interface  to  use  the  hardware.  Other  software  packages  were  used  for  word 
processing,  figure  creation,  and  remote  login  to  the  Tatung®  machine.  Commercial  software 
purchased  for  this  project  included  Microsoft  (MS)  DOS™,  Windows™,  Borland  C-H-® 
compiler,  Borland  Office  for  basic  word  processing  and  data  base  capabilities,  CorelDraw®,  and 
network  interface  tools. 

PC  Interface  Software 

CAE-Link  has  developed  software  that  provides  the  DIS  network  interface  for  the 
FED  and  the  FDS.  This  software  performs  two  basic  functions.  First,  it  performs  necessary 
DIS  simulation  functions  needed  for  operation  in  the  synthetic  environment.  This  includes 
sending  entity  state  PDUs  representing  the  entity  housing  or  controlling  the  command  and 
control  equipment  that  is  on  the  network.  The  software  also  processes  detonation  PDUs  in 
order  to  determine  if  the  entity  related  to  the  equipment  has  been  affected  by  weapons  fire. 
Secondly,  the  interface  software  handles  the  transport  of  digital  command  and  control 
information  over  the  DIS  network.  This  is  accomplished  by  receiving  the  command  and  control 
input  fix)m  the  field  wire  interface  through  the  PC  modem  board,  extracting  the  text  message, 
including  the  text  information  as  data  in  a  DIS  signal  PDU,  and  sending  the  signal  PDU  and  its 
associated  transmitter  PDUs  on  the  DIS  network  to  the  receiving  device.  The  interface  on  the 
receiving  end  does  the  opposite,  extracting  the  text  information  from  the  signal  PDU  and  sending 
the  information  to  the  command  and  control  devices  on  the  field  wire  interface  through  the 
modem  board. 

User  Interface 

The  PC  interface  software  has  a  user  interface  that  can  display  a  number  of 
different  screens.  These  screens  show  information  such  as  received  and  issued  signals,  entity 
information,  packets  received,  processed  and  lost,  and  so  forth.  This  interface  could  easily  be 
adapted  to  provide  other  valuable  DIS  network-related  information  for  the  user. 

Devices  That  May  Use  the  PC  Interface 

This  interface  is  very  flexible  and  may  be  used  with  other  digital  command  and 
control  equipment  that  uses  a  field  wire  interface.  This  was  demonstrated  during  integration 
when  a  digital  message  device  (DMD)  was  interfaced  to  the  DIS  network  using  the  same 
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interface.  Additional  modem  boards  are  required  if  the  number  of  communication  channels 
increases  with  the  addition  of  further  equipment. 

Network  Data-Logging  Software 

The  ARL  network  also  includes  limited  data-logging  capabilities  available  through 
the  use  of  the  1ST  software.  This  software  allows  the  collection  of  network  information  for 
analyzing  the  DIS  packets  being  sent  by  the  various  DIS  network  devices.  The  logger  also 
features  playback  capabilities  that  can  be  used  in  the  training  studies  to  be  performed  in  the  next 
phase  of  this  project. 

Additional  data-logging  capability  has  been  added,  allowing  the  researcher  to 
gather  time-specific  data  without  having  to  review  the  entire  PDU  structure. 

Interface  Design 

Primary  development  of  the  DIS  interfaces  took  place  at  the  CAE-Link  facilities  in 
Binghamton,  New  York.  To  support  the  Binghamton  development,  two  FEDs  and  the  FDS 
software  were  provided  by  ARL.  These  devices  were  returned  to  the  Government  with  the  rest 
of  the  system  hardware  and  software. 

Integration  of  Devices 

After  the  DIS  interfaces  were  developed  in  Binghamton,  the  hardware  and 
software  were  shipped  to  the  ARL  and  D&SA  Battle  Lab  facility  at  Fort  Sill  for  setup  and 
integration  with  other  laboratory  devices.  Integration  proceeded  at  Fort  Sill  with  CIMUL8™  and 
the  MLRS/ATACMS  FCPT. 

It  was  assumed  that  these  systems  would  be  DIS  compatible  when  integration 
began.  Discussions  about  which  version  of  DIS  would  be  used  and  how  the  integrated  system 
would  operate  were  held  throughout  development  of  the  interface.  An  interface  control 
document  (ICD)  was  developed,  which  describes  how  the  various  systems  interface  and  how  the 
DIS  PDUs  would  be  created  and  interpreted.  This  ICD  was  distributed  to  the  developers  of 
CIMUL8™  and  the  FCPT  for  use  in  developing  their  DIS  capabilities.  The  final  ICD  reflecting 
the  actual  interfaces  used  for  the  demonstrations  is  provided  in  Appendix  C.  The  developers  of 
CIMUL8™  and  the  FCPT  were  present  on  site  during  the  integration  phase  to  support  their 
devices. 
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DIS  Simulation  Concepts 

Two  scenarios  are  supported  by  the  network  of  devices  that  were  delivered.  The 
first  scenario  uses  CIMUL8™  or  the  target  acquisition  fire  support  model  (TAFSM)  to  stimulate 
the  FDS  software  with  an  FR  GRID  message  (providing  target  information).  The  FDS  then 
sends  a  call  for  fire  to  the  MLRS/ATACMS  FCPT.  The  MLRS/ATACMS  FCPT  is  responsible 
for  firing  the  weapon.  The  second  scenario  uses  a  Janus  simulation  or  CIMUL8™  to  produce 
combat  events  that  will  prompt  a  commander  to  enter  fire  missions  in  the  FED.  These  missions 
are  sent  to  the  FDS  and  the  rest  proceeds  as  in  the  first  scenario.  In  both  cases,  the  DIS  network 
is  used  to  send  the  command  and  control  information.  The  DIS  network  also  supports  entity 
information  in  the  form  of  entity  state  PDUs  and  the  firing  and  detonation  events  of  the  MLRS 
launcher  in  the  form  of  fire  and  detonation  PDUs. 

To  support  these  operational  requirements,  the  following  DIS  PDUs  fi’om  DIS 
PDU  version  2.0.3  were  used  (see  Appendix  D  for  a  detailed  listing): 

Entity  State  PDUs:  Entity  state  PDUs  (ES  PDUs)  are  issued  to  represent  the 
simulated  operator  or  vehicles  hosting  the  field  artillery  FED. 

Fire  PDUs:  The  MLRS/ATACMS  FCPT  sends  a  fire  PDU  when  it  fires  the 

launcher. 

Detonation  PDUs:  Detonation  PDUs  are  sent  by  the  MLRS/ATACMS  FCPT 
when  the  munition  it  fired  detonates  or  impacts.  The  FED  and  FDS  also  receive  detonation 
PDUs  firom  unfriendly  forces  in  order  to  determine  if  they  are  affected  by  enemy  fire  (killed). 

Transmitter  and  Signal  PDUs:  These  PDUs  are  used  to  transmit  digital 
command  and  control  message  information  between  devices. 

IMPLEMENTATION 

The  implementation  of  the  integrated  system  resulted  in  the  successful  demonstrations 
that  are  described  next. 

Results  of  Phase  II 

Two  scenarios  were  demonstrated  with  the  system  described  in  the  preceding  sections. 
The  first  scenario  demonstrated  close  operations  begiiming  with  target  identification  by  a  forward 
observer  (FO)  through  an  MLRS  rocket  launch  sequence.  In  this  scenario,  one  FED  was  used  to 
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represent  the  communications  of  an  FO,  and  the  other  FED  was  used  to  represent  the  fire 
support  team  (FIST).  The  MLRS  fire  battery  fire  direction  center  was  represented  with  the 
LCU  running  the  MLRS  battery  FDS  software.  The  MLRS  launcher  actions  were  simulated  by 
the  MLRS/ATACMS  FCPT.  CIMUL8™  provided  a  graphical  view  of  the  battle,  using  icons  to 
show  the  location  of  the  various  participants  (FO,  FIST,  fire  direction  center  [FDC],  and 
launcher)  along  with  the  simulation  of  other  fiiendly  and  opposing  forces.  In  addition, 
communications  and  weapon  firing  were  graphically  displayed  using  the  DIS  PDUs  received  on 
the  network. 

The  sequence  of  events  for  the  first  demonstration  is  shown  in  Figure  4. 


Figure  4.  Scenario  events  for  demonstration  No.  1. 

To  represent  the  deep  battle,  we  added  other  devices  to  the  network  to  be  used  in  the 
second  demonstration.  Added  were  the  FDDM  and  the  DMD.  The  final  network  configuration 
with  the  added  devices  is  illustrated  in  Figure  5. 
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Figure  5.  Demonstration  configuration  with  FDDM  and  DMD. 


The  second  scenario  representing  the  deep  battle  simulated  target  engagement  began  with 
simulated  fire  finder  target  detection  and  ended  with  simulated  launcher  rocket  fire.  The 
demonstration  began  with  the  simulated  fire  finder  radar  identifying  a  target  within  CIMUL8™. 
The  DMD  was  used  to  send  command  and  control  information  that  would  normally  be  done 
within  the  fire  finder  system.  Target  information  was  entered  on  the  DMD  and  sent  to  the 
battalion  FDDM.  The  FDDM  then  sent  the  appropriate  call  for  fire  (CFF)  to  the  MLRS  battery 
FDS.  The  FDS  then  sent  a  CFF  to  an  MLRS  launcher  that  was  simulated  in  CIMUL8™.  This 
scenario  is  shown  in  Figure  6.  The  CFF  format  to  guide  preparation  of  correct  tactical  fire 
direction  system  (TACFIRE)  message  formats  is  presented  in  Appendix  E. 
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BN  FDDM  receives  the 
target  information, 
determines  which  btry  will 
handle  the  mission,  and 
sends  a  Call  For  Fire  to 
the  MLRSBtryFDC 


FDC  receives  the  Call  for  Fire  from  BN 
and  generates  an  MLRS  Call  For  Fire. 
The  Call  For  Fire  is  issued  to  the  assigned 
MLRS  launcher. 


(J)  The  MLRS  Launcher  receives**  the 
CFF  and  carries  out  the  firing  mission 
by  firing  six  M2  6  rockets. 


**  For  this  demonstration,  CIMUL8  was  unable  to  receive  the  CFF 
message.  The  receipt  of  the  CFF  was  simulated. 


Figure  6.  Scenario  events  for  demonstration  No.  2. 


The  demonstrations  showed  the  success  of  using  the  DIS  network  for  communicating 
digital  command  and  control  information. 

Problems  That  Were  not  Resolved 
Acknowledgment  Messages 

Although  the  network  design  with  the  original  group  of  devices  (not  including  the 
DMD  and  the  FDDM)  operated  successfully  on  the  LAN,  it  was  noted  that  network  traffic  and 
preamble  settings  on  the  command  and  control  devices  could  affect  the  abihty  of  the  receiving 
devices  to  provide  acknowledge  (ACK)  messages  in  time  for  the  sending  device  to  “know”  that 
the  transmission  was  successful.  The  devices  have  a  built-in  mechanism  as  part  of  their 
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communications  protocols,  which  will  attempt  to  retransmit  the  message  as  many  as  three  more 
times  after  the  first  message  fails  (no  ACK  received  within  the  specified  ACK  window  time). 

For  the  program  network  devices,  the  preamble  settings  were  set  so  that  the  ACK 
window  was  larger,  thus  allowing  the  FEDs  more  time  to  return  the  ACK  to  the  FDS.  Even  with 
increased  network  traffic  loads  (CIMUL8™  representing  as  many  as  30  entities  actively  engaged 
in  combat),  these  settings  worked. 

When  the  FDDM  and  the  DMD  were  added  to  the  network,  we  were  unable  to 
adjust  the  settings  on  the  FDDM  and  the  FDS  so  that  they  could  provide  the  needed  ACK  over 
the  network  in  time.  This  also  highlighted  the  problem  that  could  occur  if  the  system  were  used 
over  a  long-distance  network  such  as  DSL  The  transport  times  for  the  DIS  PDUs  would  be  such 
that  the  ACK  window  would  be  impossible  to  meet. 

In  addition,  the  MLRS/ATACMS  FCPT  software  did  not  send  an  ACK  at  all 
when  a  signal  PDU  was  received.  To  prevent  the  FDS  from  attempting  to  resend  the  same  CFF 
message  to  the  FCPT,  an  ACK  is  needed  for  the  FDS  software. 

The  short-term  solution  was  to  design  the  PC  interface  so  that  it  provided  the 
necessary  ACK  to  the  sending  device  so  that  the  device  would  not  attempt  to  resend.  This 
approach  has  been  implemented  for  the  FDS.  The  FDS  PC  interface  will  provide  an  ACK  to  the 
FDS  device  for  command  and  control  messages  sent  to  the  MLRS/ATACMS  FCPT.  This  ACK 
is  on  the  1 1 -character  net.  An  ACK  has  not  been  implemented  for  the  6-character  net,  but  with 
minimal  effort,  it  could  be  added. 

The  long-term  solution  is  to  allow  the  PC  interface  to  act  as  a  “relay”  for 
messages.  Digital  command  and  control  communication  devices  have  the  capability  to 
automatically  relay  or  forward  messages  received  from  one  device.  When  this  function  is 
implemented,  the  relayer  provides  the  ACK  needed  by  the  sender.  The  advantage  is  that  the  PC 
interface  would  not  have  to  generate  different  ACK  messages  for  the  different  t3Tpes  of  messages 
sent  through  the  interface. 

MLRS/ATACMS  FCPT  DIS  Capabilities 

The  MLRS/ATACMS  FCPT  has  DIS  PDU  version  2.0.3  capabilities.  However, 
the  capabilities  are  limited  and  not  fully  DIS  compliant.  These  are  described  as  follow: 
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1.  Issues  entity  state  PDUs  on  behalf  of  the  MLRS  launcher  vehicle.  The  sending 
of  the  PDUs  is  event  driven  rather  than  time  driven.  These  are  sent  when  the  system  is  started 
and  before  and  after  moving  (this  does  not  follow  the  once-every-5-second  rule  in  the  standard). 

2.  Issues  a  fire  PDU  for  each  rocket  fired  in  the  exercise.  Currently  configured  to 
fire  six  rockets. 

3.  Issues  a  detonation  PDU  after  the  fiise  time  has  expired.  The  demonstration 
version  used  only  a  single  detonation  for  all  six  rockets  fired.  The  delivered  system  sends 
detonation  PDUs  for  each  of  the  six  rockets. 

4.  Transmitter  and  signal  PDUs  are  used  to  send  related  command  and  control 
message  formats.  The  messages  sent  included  response  to  CFF  (WILCO  or  CANCO)  and  a 
mission-fired  message. 

5.  The  FCPT  receives  transmitter  and  signal  PDUs  with  CFF  messages  from  the 
FDS.  An  acknowledge  message  is  not  provided. 

CIMUL8™  Use  of  the  FR  GRID  Message 

The  FR  GRID  message  issued  by  CIMUL8™  operates  well  for  the  evaluation  of 
the  trainer.  At  this  point,  it  is  a  fixed  message.  More  work  will  be  required  to  make  the  message 
more  flexible. 

Potential  Problems 

Until  the  remainder  of  the  ACK  problem  is  addressed,  transmission  problems  could  occur 
if  die  network  becomes  loaded  or  if  the  long-distance  network  incurs  excessive  delays.  The 
effects  of  network  loading  on  the  PC  interface,  CIMUL8™,  and  the  FCPT  have  not  been  studied. 
The  point  at  which  the  interfaces  begin  to  lose  DIS  packets  has  not  been  determined.  During 
conditions  created  during  the  demonstration  week,  it  was  shown  that  the  system  (without  the 
FCPT)  worked  well  with  approximately  35  entities  actively  engaged  in  combat  (maneuvering  and 
firing).  In  this  scenario,  the  PC  experienced  no  lost  network  packets. 
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RECOMMENDATIONS 

Following  the  successful  demonstrations,  several  recommendations  for  improvements 
were  made.  These  recommendations  are  explained  next. 


Addition  of  Other  Command  and  Control  Systems 

A  significant  step  has  been  taken  toward  bringing  real-world  command  and  control 
systems  into  the  synthetic  environment  for  training,  testing,  evaluation,  and  data  collection 
purposes.  The  same  interface  used  in  the  demonstration  discussed  previously  can  also  be  used 
with  other  existing  command  and  control  devices  and  could  serve  as  a  means  to  test  the 
interaction  of  new  and  developing  command  and  control  equipment. 

The  interface  developed  for  ARE  and  the  D&SA  Battle  Lab  has  been  shown  to  work  with 
FEDs,  DMDs,  FDDM  and  battery  FDS  systems.  Unmodified,  it  is  anticipated  that  the  same 
interface  will  also  work  with  other  command  and  control  computers.  These  include  FDS  at  the 
platoon  and  battalion  levels,  TACFIRE,  lightweight  TACFIRE  (LTACFIRE),  the  cannon  battery 
computer  system  (BCS),  the  all-source  analysis  system  (ASAS),  the  airborne  target  hand-over 
system  (ATHS),  IFSAS,  the  ground  station  module  (GSM),  and  the  commander’s  tactical 
terminal  (CTT).  Some  of  these  devices  are  shown  in  Figure  7. 


Figure  7.  Expanding  the  command  and  control  network. 
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Interface  with  the  GSM  and  the  CTT  provides  a  digital  communications  link  to  Air  Force 
and  Army  sensor  systems  such  as  the  joint  surveillance  target  attack  radar  system  (JSTARS),  the 
OV-ID  Mohawk  side-looking  airborne  radar  (SLAR),  and  the  guardrail  signals  intelligence 
(SIGINT)  system.  Other  systems  conmiunicating  with  the  GSM  include  maneuver  control 
system  (MCS)  and  the  forward  area  air  defense  command  and  control  (FAADC2). 

In  addition,  the  interface  could  be  used  to  allow  new  and  developing  systems  to  test  their 
capabilities  with  existing  systems  in  the  DIS  environment.  These  include  die  advanced  field 
artillery  tactical  data  system  (AFATDS),  the  improved  data  modem  (IDM),  and  the  aviation 
mission  planning  system  (AMPS). 

Compatibility  with  Television  Network  (TNET) 

The  existing  network  could  work  over  the  TNET,  provided  TNET  has  an  Ethernet 
interface  and  is  able  to  transmit  local  area  network  information  to  remote  Ethernet  networks. 

One  possible  solution  is  to  add  a  PC  interface  for  TNET,  which  has  an  Ethernet  card  and 
an  RS-232  interface  to  the  COMSEC.  In  addition  to  passing  information  to  and  from  TNET,  the 
PC  can  serve  as  a  filter  for  the  local  area  network.  One  possible  configuration  is  shown  in 
Figure  8. 


Figure  8.  TNET  network  configuration. 
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A  repeater  is  required  for  this  configuration  because  of  the  distance  between  the  network 
and  the  TNET  COMSEC.  A  PC  would  be  used  to  connect  the  Ethernet  network  with  the 
COMSEC  through  the  COMSEC  9-pin  RS-232  port.  A  similar  setup  would  be  required  at  the 
receiving  end.  There  are  some  bandwidth  limitations  with  using  the  9-pin  RS-232  port  (128 
Kbps).  If  possible,  the  COMSEC  RS-422  port  could  be  used  to  employ  more  bandwidth. 

Enhanced  Data  Collection  Capabilities 

Based  on  the  development  already  performed,  one  area  needing  further  capabilities  is  data 
collection.  The  IST-developed  data  logger,  already  a  part  of  the  ARL  network,  can  capture  DIS 
PDUs  and  provides  human  readable  text  files  for  reading  the  values  of  the  fields  in  the  PDUs. 

The  data  logger  does  not  process  this  data,  nor  does  it  allow  for  data  collection  of  specific 
information. 

To  upgrade  the  data  collection  capabilities  of  the  ARL  network,  a  first  step  could  be  to 
develop  software  to  process  the  data-logged  information  for  presentation  to  the  user.  This  could 
be  accomplished  by  modifying  the  data  logger  to  save  only  the  necessary  information  instead  of 
the  entire  PDU.  This  information  would  be  saved  directly  into  a  relational  data  base  for  easy 
report  generation.  Certainly,  any  data  sent  on  the  DIS  network  could  be  captured  and  processed 
in  this  manner. 

For  that  cannot  be  captured  on  the  DIS  network,  a  number  of  capabilities  would  need 
to  be  developed  to  collect  the  needed  data.  The  device  from  which  the  data  need  to  be  collected 
would  have  to  have  the  capability  to  provide  that  information  upon  request.  The  request  for  the 
data  could  be  made  over  the  DIS  network  using  the  simulation  management  PDUs.  These  PDUs 
allow  a  simulation  manager  to  request  certain  parameters  or  event  information  from  a  participant 
on  the  DIS  network,  provided  the  participant  has  the  ability  to  provide  the  information.  The 
simulation  management  PDUs  also  provide  simulation  control  capabilities  such  as  simulation 
start,  entity  creation,  and  simulation  freeze,  restart  and  stop.  These  capabilities  would  have  to  be 
supported  by  the  participants  on  the  DIS  network  to  use  the  simulation  management  PDU  set. 

Another  possible  enhancement  of  the  ARL  network  would  be  to  add  support  for  the 
simulation  management  PDUs.  This  would  be  a  significant  development  effort  since  no  full 
implementations  of  the  simulation  management  PDUs  exist  today.  It  could  serve  as  a  model  for 
other  systems  and  provide  valuable  feedback  to  the  DIS  standards  as  they  continue  in  their 
development. 
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Enhanced  Support  for  Command  and  Control  Devices 

To  support  long-distance  networking  of  a  large  variety  of  command  and  control  systems, 
the  interface  software  already  developed  needs  further  refinement.  The  existing  interface  allows 
the  digital  communication  devices  to  communicate  through  their  field  wire  interface,  allowing 
them  to  use  the  same  physical,  data  link,  network  and  transport  layer  protocols  that  are  used  in 
the  field.  Part  of  the  transport  layer  protocol  is  to  ensure  reliable  communications  by  requiring 
the  receiving  system  to  send  an  ACK  indicating  that  the  message  was  successfully  received.  If 
the  ACK  is  not  received  by  the  sender  within  a  certain  predetermined  period  of  time,  the  sender 
attempts  to  retransmit  the  message,  returning  an  error  message  to  the  operator  after  three 
unsuccessful  attempts  to  resend.  On  the  original  demonstration  network,  ACKs  were 
successfully  sent  by  the  receiving  system  over  the  network.  There  is  concern  that  additional 
network  traffic  and  the  introduction  of  the  long  distance  will  cause  enough  delay  in  the  sending  of 
the  ACK  so  that  it  will  not  be  received  in  time  by  the  sender  of  the  message. 

Since  this  project  does  not  modify  the  software  on  the  command  and  control  devices,  the 
interface  for  the  sending  system  will  need  to  provide  the  ACK  for  the  sending  communication 
device  in  order  for  the  ACK  to  be  returned  to  the  sender  in  time. 

Enhanced  Entity  Representation 

The  completed  demonstration  system  does  not  do  detailed  entity  representation.  The 
DIS  entity  operating  the  command  and  control  equipment  using  the  interface  is  stationary.  The 
entity  movement  is  not  modeled,  although  an  instant  move  is  possible.  To  provide  realistic 
entity  movement,  a  terrain  data  base  will  be  necessary  for  realistic  representation  in  a  three- 
dimensional  view  of  die  battlefield.  Movement  models  would  also  be  necessary. 

A  possible  solution  would  be  to  add  these  capabilities  in  the  interface  software.  Terrain 
information,  along  with  movement  models,  would  be  required.  Another  solution  would  be  to  use 
an  existing  computer-generated  forces  (CGF)  system  to  control  the  appearance  and  movement  of 
the  entity  in  the  synthetic  environment.  The  PC  interface  would  then  be  used  for 
communications  and  radio  representation  only.  This  represents  a  step  toward  distributed 
representation  of  a  single  entity—a  fairly  new  concept  in  the  DIS  world. 

CIMUL8™  might  be  used  as  the  CGF  for  entity  control  and  movement.  This  system 
already  exists  on  the  ARE  network.  A  PC-based  system  such  as  IST’s  CGF  (software  already 
existing  in  D&SA  and  DIS  compliant)  might  also  be  used  to  move  command  and  control  entities. 
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provided  some  modifications  are  made  to  adapt  it  for  the  ARL  situation.  This  would  provide  a 
PC-based  solution  that  is  relatively  low  cost  and  available  to  other  sites.  A  third  possibility 
would  be  to  obtain  a  system  such  as  the  DIS-compatible  interactive  tactical  environment 
management  system  (ITEMS™).  ITEMS™  can  provide  simulation  for  the  command  and  control 
entities  and  can  provide  a  three-dimensional  stealth  view  of  the  battlefield.  In  addition,  the 
flexibility  of  the  ITEMS™  data  base  management  system  (DBMS)  allows  for  user  definition  of 
vehicles,  weapons,  and  their  characteristics— ideal  for  an  experimentation  and  testing  environment. 

All  the  CGF  systems  mentioned  previously  would  require  the  development  of  terrain 
data  bases  for  the  area  to  be  used  for  maneuvers.  Data  bases  may  already  exist  for  many  areas  of 
interest. 

Enhanced  Radio  Representation 

Command  and  control  devices  typically  communicate  using  FM  radios  and  encryption 
devices.  Representations  for  use  of  these  devices  in  a  radio  environment  could  be  further 
enhanced  by  allowing  transmitted  signals  to  be  jammed  or  masked  by  terrain.  Currently,  the 
system  assumes  perfect  transmissions. 

Terrain  representation  is  required  to  determine  line  of  sight.  Other  environmental  factors 
may  be  required,  depending  on  the  fidelity  of  the  propagation  model  to  be  used.  Detection  and 
jamming  should  also  be  allowed. 

CONCLUSION 

The  development  of  an  interface  for  fire  support  command  and  control  tactical  equipment 
into  the  synthetic  environment  represents  the  first  time  soldiers  operating  live  equipment  have 
been  able  to  interact  with  soldiers  operating  training  devices  in  a  virtual  arena  on  a  computer¬ 
generated  battlefield  populated  by  computer-generated  equipment  and  forces  produced  by  a 
constructive  simulation,  linking  live,  virtual,  and  constructive  simulations  in  a  seamless  manner. 
Currently,  the  potential  to  link  within  and  between  simulation  categories  varies  from  good  (in  the 
case  of  constructive-to-constructive  simulations)  to  very  limited  (in  the  live-to-live  category). 
Improvement  in  this  area  is  critical  to  the  utility  of  this  concept  to  support  Department  of 
Defense  (DoD)  readiness  requirements. 
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Decreasing  resources  and  environmental  restraints  and  the  increasing  amormt  of  land 
required  by  advances  in  mobility  and  weapon  system  lethality  are  limiting  our  ability  to 
effectively  and  efficiently  conduct  tough  and  realistic  field  exercises  for  training,  testing,  or 
research  and  development.  The  Army  must  apply  major  technological  advancements  to  the 
training,  testing,  and  research  and  development  arena  just  as  it  has  to  the  operational  arena.  Just 
as  digitization  is  revolutionizing  command,  control,  communications,  computers,  and  intelligence 
(C4I)  for  the  field  forces,  advances  in  computer  capabilities  are  revolutionizing  the  training 
battlefield  and  the  way  that  testing  and  research  and  development  are  conducted. 

Described  in  this  report  was  the  formation  of  a  fire  support  command  and  control  test 
bed  that  centered  around  the  development  of  a  software  interface  that  allowed  live  tactical 
command  and  control  equipment  to  interact  in  a  seamless  fashion  with  computer-generated  forces 
arrayed  on  the  synthetic  battlefield.  The  next  step  will  be  to  evaluate  this  technology  to 
determine  its  feasibility  to  support  training,  testing,  and  research  and  development.  The  ARL 
and  the  D&SA  Battle  Lab  will  demonstrate  and  begin  to  assess  the  utility  of  the  technology 
during  advanced  warfighting  experiments  and  during  Battle  Lab  experimentation  initiatives  such 
as  intrepid  vision,  digitization  experimentation  in  the  Janus  battle  simulation  center,  synthetic 
theater  of  war  initiatives,  and  prairie  warrior. 
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ACRONYM  LIST 


ACK 

type  of  signal  that  acknowledges  receipt  of  a  command  and  control  message 

AFATDS 

advanced  field  artillery  tactical  data  system 

AMPS 

aviation  mission  planning  system 

ADDS 

Army  data  distribution  system 

ARL 

Army  Research  Laboratory 

ARP 

address  resolution  protocol 

ASAS 

all-source  analysis  system 

ATACMS 

Army  tactical  missile  system 

ATHS 

airborne  target  hand-over  system 

BCS 

battery  computer  system 

CADIS 

communication  architecture  for  DIS 

CFF 

call  for  fire 

CGF 

computer-generated  forces 

COTS 

commercial  off  the  shelf 

CTT 

commander's  tactical  terminal 

D&SA 

Depth  and  Simultaneous  Attack 

DBMS 

data  base  management  system 

DIS 

distributed  interactive  simulation 

DMD 

digital  message  device 

DSI 

defense  simulation  internet 

EPLRS 

enhanced  position  location  reporting  system 

ES 

entity  state 

FAADC2 

forward  area  air  defense  command  and  control 

FCPT 

fire  control  panel  trainer 

FDC 

fire  direction  center 

FDDM 

fire  direction  data  manager 

FDS 

fire  direction  system 

FED 

forward  entry  device 

FIST 

fire  support  team 

FO 

forward  observer 

FOCC 

forward  observer  command  and  control 

FO  CMD 

type  of  message  used  by  a  forward  observer  to  report  changes  in  fire 
mission  commands.  (Also  used  by  a  firing  unit  to  report  firing  status.) 
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FRGRID 

Type  of  message  used  to  initiate  a  fire  request  by  reporting  a  target  location 
using  grid  coordinates. 

FSATS 

fire  support  automated  test  system 

FSK 

frequency  shift  keying 

FSO 

fire  support  officer 

GSM 

ground  station  module 

ICD 

interface  control  document 

IDM 

improved  data  modem 

IFSAS 

interim  fire  support  automation  system 

ISO 

International  Organization  for  Standardization 

1ST 

Institute  for  Simulation  and  Training 

ITEMS 

interactive  tactical  environment  management  system 

Janus 

a  two-sided,  interactive,  closed,  stochastic  ground  combat  simulation  capable  of 
portraying  virtually  any  tactical  situation  or  the  effects  of  any  weapon  system. 

JSTARS 

joint  surveillance  target  attack  radar  system 

LAN 

local  area  network 

LCU 

lightweight  computer  unit 

LTACFIRE 

lightweight  TACFIRE 

MCS 

maneuver  control  system 

MLRS 

multiple  launch  rocket  system 

OSI 

open  systems  interconnection 

PC 

personal  computer 

PDU 

protocol  data  unit 

PIU 

PC  interface  unit 

SIGINT 

guardrail  signals  intelligence  system 

SLAR 

side-looking  airborne  radar 

SPECT8TM  -X 
CIMULS™  > 
DISIPS™ 

a  proprietary  simulation  software  program  that  provides  information, 
display  and  a  digital  simulation  capability 

SHTU 

simplified  hand-held  terminal  unit 

TACFIRE 

tactical  fire  direction  system 

TAFSM 

target  acquisition  fire  support  model 

TCIM 

tactical  communications  interface  module 

UCF 

University  of  Central  Florida 

UDP/IP 

user  datagram  protocol/intemet  protocol 

WAN 

wide  area  network 

WILCO 

will  comply 
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HARDWARE,  SOFTWARE,  AND  GOVERNMENT- 
PROVIDED  EQUIPMENT  REQUIREMENTS 


_ NETWORK  REQUIREMENTS _ 

iTY _ MODEL _ I _ DESCRIPTION/MINIMUM  SPECS 

X""!  '7'  "  HABjywAM  . '■ 

3  486  PC  SOMhz  (Intel  DX  Processor)  256  Cache  _ 

SMB  RAM _ 

200MB  Hard  Drive _ _ 

5.25"  (1.2MB)  Floppy  Drive 

3.5"  (1.44MB)  Floppy  Drive _ 

Etherlink  HI  Network 

Interfaces  (by  3COM) _ 

8  Port  RS-232  Interface _ 

2  -  Serial  Ports _ 

1  -  Parallel  Port 

VGA  Card  _ 

14"  VGA  Monitor _ 

101  Key  Keyboard _ 

Microsoft  compatible  mouse _ 

2  Telos®  Signal  Ma<iter _  Programmable  Communications  Controller 

1  lOBaseT  Concentrator  or  Wiring  Hub  8  Node  Minimum _ 

8  lOBaseT  (802.3)UTP  Cables  50'  Length _ 

1  Super  Compstation  7/30  36MHz  (SPARC  19"  Tatung®  Color  Monitor 

compatible)  _ 

GX  Graphic  Accelerator _ 

32MB  Main  Memory _ 

1.08  GB  Internal  Hard  Drive _ 

8  Memory  Slots  (max.  256  MB  memory) _ 

Ethernet  interface _ 

107-key  Keyboard _ 

Mechanical  Mouse _ 

Solaris  2.1  software  installed  (includes:  open  Windows, 
open  Look,  XI1R5  MOTIF) _ 
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MODEL 


Super  Compstation  7/30  36Mhz  (SPARC 
compatible) 


Desktop  MLRS/ATACMS  Fire  Control 
Panel  Trainer 


NETWORK  REQUIREMENTS  Icont’d 


DESCRIPTION/MINIMUM  SPECS 


19"  Tatung®  Color  monitor 


GX  Graphic  accelerator 


32MB  Main  memory 


1.08  GB  Internal  hard  drive 


8  Memory  slots  (max.  256MB  memory) 


Ethernet  inter&ce 


107  Key  Keyboard 


Mechanical  mouse 


Solaris  2.1  software  installed  (includes:  open  Windows, 
open  Look,  XIIR5  MOTIF) 


150MB  External  Cartridge  Tape  Drive 


680MB  CD-ROM  External  SCSI  Drive 


(by  LORAL/Vought  Systems) 


Ethernet  Transceiver 


Ethernet  Accessories 


Dot  Matrix  printer 


Vampire  Tap 


Transceiver  plenum  cable  (50  ft).  Coring  Tool  &  Allen 


(on  loan  from  CAE-Link) 


3 

MS-DOS  6.0 

3 

MS-WINDOWS  3.1 

3 

Norton  Desktop  Utilities 

2 

Borland  C-H-®  Compiler 

3 

HEAP  Expander 

2 

Communications  Library 

1 

Borland  OflBce 

1 

CoreIDraw®3 

3 

PC/TCP  4 

’  The  Tool  Makers)  memory  management  software 


Commumcations  Library  for  communications  with  RS- 
232  &  Ethernet  (Company  as  recommended  by 
manufacturer  of  the  8  port  cards) 


(Includes:  WordPerfect  for  Windows  5.2,  Paradox  for 
Windows,  QuattroPro  for  Windows) 


(By  FTP  software,  version  as  recommended  by  the 
manufacturer  of  the  3C503  board) 
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1  NETWORK  REQUIREMENTS  (cont'd) 

QTY 

MODEL 

DESCRIPTION/MINIMUM  SPECS 

2 

TM  TM  TM 

SPECT8  /CIMUL8  /DISIP8 

(By  BDM  International  Inc) 

2 

GKS-X-X-X-RT 

’’Right  to  Use"  license  for  SUN  GKS 

GOVERNMENT  FURNISHED  EOiflPMENT 

2 

Forward  Entry  Device  (FED) 

Including  power  and  data  cables 

1 

Lightweight  Computer  Unit 
(LCU) 

(with  Fire  Direction  System  (FDS)  software  installed) 

N/A 

TACFIRE  Interfece  specifications 

(From  Software  Engineering  Directorate,  Fire  Support 
Software  Division) 

1 

Fire  Support  System  Simulation  (FS3) 
software 

(From  Software  Engineering  Directorate,  Fire  Support 
Software  Division) 

1 

Digital  Message  Device 

Added  for  Demonstration  #2 

1 

Fire  Direction  Data  Manager 

Added  for  Demonstration  #2 
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1.0 


INTRODUCTION 


This  interface  specification  was  developed  in  support  of  the  Army  Research  Laboratory  (ARL) 
sponsored  project  to  instrument  the  Depth  and  Simultaneous  Attack  (D&SA)  Battle  Lab  with 
Fire  Support  command  and  control  equipment  using  the  Distributed  Interactive  Simulation  (DIS) 
protocols  on  a  Local  Area  Network  (LAN).  The  purpose  of  this  laboratory  is  to  simulate 
realistic  battlefield  communications  conditions  for  research  and  training.  Devices  to  be  integrated 
into  this  simulation  capability  include:  Forward  Entry  Device  (FED),  Fire  Direction  System 
(FDS),  and  the  Multiple  Launch  Rocket  System/Army  Tactical  Missile  system 
(MLRS/ATACMS)  Fire  Control  Panel  Trainer  (FCPT). 

The  integration  of  these  devices  onto  an  instrumented  LAN  will  permit  the  conduct  of  realistic 
Fire  Support  command  and  control  exercises  to  be  conducted  in  conjunction  with  JANUS,  or  any 
other  simulation  system,  using  real  soldiers  performing  tasks  in  the  laboratory  as  they  would  in 
the  field.  This  simulation  capability  will  be  further  augmented  with  the  integration  of 
SPECT8™/CIMUL8™/DISIP8™. 

With  the  eventual  installation  of  a  Wide  Area  Network  (WAN),  laboratory  personnel  will  have 
the  capability  to  participate  in  DIS  exercises  with  participants  located  at  remote  locations. 

1.1  BACKGROUND 

1.1.1  Operation  of  the  Integrated  System 

There  are  two  applications  for  which  the  integrated  system  will  be  utilized  to  support  laboratory 
experiments.  One  application  will  call  for  a  Forward  Observer  (FO)  or  Fire  Support  Team 
(FIST)  to  enter  target  information  or  calls  for  fire  through  the  FED.  This  information  will  be 
transmitted  to  the  FDS  (serving  as  a  battery  FDS)  via  a  DIS  network  rather  than  through 
conventional  means  such  as  a  radio  or  two  wire  communications.  The  FED  message  will  be 
received  by  the  battery  FDS  and  the  battery  FDS  operator  will  then  assign  the  mission  to  the 
MLRS/ATACMS  FCPT.  The  FDS  will  make  the  assignment  by  passing  on  the  call  for  fire  to 
the  launcher  via  the  DIS  network.  When  the  MLRS/ATACMS  FCPT  receives  the  mission  it 
presents  the  mission  information  to  the  operator  to  be  acted  on  accordingly.  Finally,  the 
MLRS/ATACMS  FCPT  operator  will  enter  the  correct  inputs  in  response  to  the  message 
(usually  to  fire  the  lavmcher),  at  which  time  the  laimcher  interface  will  issue  the  appropriate  DIS 
Protocol  Data  Unit  (PDU)  for  firing  and  detonation  of  munitions. 

The  second  application  is  similar  to  the  first,  except  the  FED  and  the  FDS  are  not  included  as 
part  of  the  scenario.  The  SPECT8/CIMUL8/DISIP8  software  will  produce  the  proper  launcher 
messages  to  stimulate  the  MLRS/ATACMS  FCPT.  The  MLRS/ATACMS  FCPT  operator  will 
respond  to  the  inputs  in  the  appropriate  maimer. 

The  functional  configuration  for  the  integrated  network  is  shown  in  Figure  C-1. 
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Figure  C-1.  Network  configuration  for  ARL/Ft  Sill. 

A  description  of  the  various  devices  on  the  network  is  included  in  the  paragraphs  that  follow. 

1.1.2  Forward  Entry  Device 

The  FED  Forward  Observer  Command  and  Control  (FOCC)  device  is  a  hand-held  digital  device 
that  is  used  to  compose,  edit,  transmit,  receive,  display,  store,  or  recall  digital  messages.  The 
FED  FOCC  is  used  by  FO's,  FIST's,  and  FSO's  to  conduct  and  plan  fire  support  operations  and 
by  survey  parties  to  display  and  transmit  manually  entered  survey  command  and  control  data  to 
another  FED  FOCC.  Tiie  FED  FOCC  also  has  a  graphics  capability  that  enables  the  display  of 
pertinent  tactical  military  s5anbols  and  other  graphical  information. 

The  FED  FOCC  has  the  capability  for  two-way  communications  through  the  use  of  a  single 
communications  port  using  either  the  Frequency  Shift  Keying  (FSK)  communications  protocol 
over  standard  army  tactical  communications  equipment  or  the  Army  Data  Distribution  System 
(ADDS)  communications  protocol  over  the  Enhanced  Position  Location  Reporting  System 
(EPLRS). 
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The  FED  software  is  executed  on  a  standard  AN/PSG-7  Simplified  Handheld  Terminal  Unit 
(SHTU). 


1.1.3  Fire  Direction  System 

The  FDS  is  the  computer  system  that  provides  tactical  fire  control  for  the  MLRS  platoon, 
battery,  and  battalion  levels.  For  the  purposes  of  the  Fort  Sill  laboratory  interface,  our  FDS  will 
be  operating  at  the  battery  level.  The  FDS  is  responsible  for  determining  those  targets  to  be  fired 
upon,  those  fire  units  capable  of  firing  at  the  target,  and  the  amount  of  ammunition  to  be  used 
against  a  given  target. 

The  FDS  software  is  executed  on  a  standard  AN/GYK-37V,  Lightweight  Computer  Unit  (LCU). 
FDS  equipment  also  includes  a  printer,  AC/DC  Converter/Charger,  a  Tactical  Communications 
Interface  Module  (TCIM),  and  a  TCIM  wire-line  adapter. 

1.1.4  Multiple  Launch  Rocket  System  Fire  Control  Panel  Trainer 

The  MLRS/ATACMS  FCPT  is  a  desk  top  device  for  training  soldiers  in  the  use  of  the 
MLRS/ATACMS  Fire  Control  Panel.  This  training  has  traditionally  been  accomplished  on  a 
larger,  more  expensive  institutional  training  system.  Installed  on  a  486  PC  compatible  computer 
running  an  OS/2  operating  system,  this  device  is  less  expensive  and  more  portable  than  the 
institutional  trainer. 

A  DIS  interface  capability  has  been  added  to  the  FCPT  for  this  project.  The  trainer  plugs 
directly  into  the  10-Base  T  Ethernet  network. 

1.1.5  SPECT8/CIMUL8/DISIP8 

SPECT8/CIMUL8  is  a  computer  simulation  model  for  addressing  military  problems  at  several, 
user-selected,  levels  of  detail.  It  is  a  graphics  tool  that  assists  the  user  in  setting  up  scenarios, 
observing  the  model's  operation,  interacting  with  the  model,  and  post-processing. 
SPECT8/CIMUL8  can  also  be  used  in  a  stand-alone  mode  for  analyzing  other  model  output,  field 
test  data,  etc.  DISIP8  provides  the  capability  for  SPECT8/CIMUL8  to  interact  with  other 
simulations  using  DIS. 

SPECT8/CIMUL8/DISIP8  runs  on  a  Tatung  (SPARC  compatible)  workstation. 

1.1.6  PC  Interfaces 

Two  PC  interfaces,  called  PC  Interface  Units  (PIU's),  are  used  to  provide  a  connection  to  the  DIS 
network  for  the  FED  and  the  FDS.  The  PIU's  are  responsible  for  creating  and  sending  DIS 
PDUs,  including  PDUs  containing  the  TACFIRE  messages  exchanged  between  devices.  The  PIU 
also  receives  and  interprets  DIS  PDUs  from  the  network  and,  when  necessary,  provides 
TACFIRE  information  fi:om  the  Signal  PDUs  to  the  FED  or  FDS. 

The  PIU's  are  hosted  on  IBM™  compatible  PC's  with  Intel™  80486  processors. 
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1.2 


DOCUMENT  OVERVIEW 


Section  1  has  provided  an  overview  of  how  the  integrated  system  operates  and  briefly  described 
its  individual  parts.  Section  2  describes  the  high  level  interface  concept  for  the  system.  Section 
3  provides  the  details  for  the  various  interfaces  discussed  in  Section  2,  including  the  DIS  PDU 
interface,  UDP/IP  usage,  and  Ethernet  usage. 

2.0  GENERAL  INTERFACE  CONCEPT 

The  present  interface  design  supports  two  concepts  of  operation  for  the  integrated  system.  The 
first  consists  of  using  the  FED  and  the  battery  FDS  to  provide  firing  events  for  the 
MLRS/ATACMS  FCPT  on  the  network.  The  second  uses  SPECT8/CIMUL8/DISIP8  to 
provide  firing  events  directly  to  the  MLRS/ATACMS  FCPT. 

2.1  GENERAL  ASSUMPTIONS 

This  section  describes  the  assumptions  for  development  of  DIS  interfaces  for  the  ARL/Fort  Sill 
laboratory. 


2.1.1  Use  of  DIS  PDU  Version  2.0.3 

DIS  PDU  version  2.0.3  shall  be  used  for  this  interface.  Only  DIS  PDUs  required  to  simulate  the 
integrated  system  will  be  required.  DIS  PDUs  shall  be  used  in  the  following  manner  for  the 
integrated  system: 


1.  TACFIRE  message  traffic  shall  be  communicated  using  Transmitter  and  Signal 
PDUs.  Receiver  PDUs  are  not  required. 

2.  Entity  State  PDUs  shall  be  issued  on  behalf  of  the  entity  containing  or 
controlling  the  transmitting  device.  Articulated  parts  are  not  required. 

3.  Fire  and  Detonation  associated  with  the  munition  fired  by  the 
MLRS/ATACMS  FCPT  shall  be  commimicated  using  the  Fire  PDU  and  the  Detonation  PDU 
respectively. 


2.1.2  Use  of  CADIS  Version  1.0 

The  Communication  Architecture  for  DIS  (CADIS)  draft  standard  version  1.0  shall  be  used  with 
this  interface.  Protocols  to  be  used  on  the  local  area  network  are: 


Application.  Presentation  &  Session  Lavers: 
Transport  &  Network  Laver: 

Data  Link  Laver: 

Physical  Laver: 


DIS  2.0.3 

DP/IP  (CADIS  1.0) 

Ethernet 

Ethernet 
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2.13 


Radio  Simulation 


Simulation  of  the  actual  radios  along  with  associated  jamming,  noise,  interference,  etc.  will  not  be 
represented  in  this  integrated  system.  It  is  assumed  that  the  devices  send  and  receive  perfect 
signals.  It  is  also  assumed  that  for  this  application,  all  devices  are  tuned  to  the  same  radio 
frequency. 


2.1.4  Entity  Information 

Entity  information  for  the  entities  associated  with  the  transmitter  shall  be  issued  in  accordance 
with  the  DIS  PDU  2.0.3  standard.  FEDs  and  FDS  will  be  associated  with  either  dismounted 
infantry  or  a  specific  vehicle.  The  MLRS/ATACMS  FCPT  will  be  associated  with  the  MLRS 
carrier  vehicle.  CIMUL8  will  represent  its  entities  with  the  appropriate  Entity  State  PDUs. 

FED  and  FDS  related  entities  will  not  maneuver  while  the  simulation  is  running.  There  will  be  an 
offline  capability  to  "Beam"  the  FED  and  FDS  entities  to  various  locations  on  the  battlefield. 

CIMUL8  entities  may  maneuver  during  the  simulation.  Movement  will  be  communicated  using 
Entity  State  PDUs. 

2.2  INTEGRATED  SYSTEM  USE  WITH  THE  FED,  FDS,  AND  MLRS/ATACMS  FCPT 

Simulation  of  the  battle  may  be  represented  by  CIMUL8,  JANUS  or  any  other  simulation  on  the 
LAN  or  DSL  Battle  information  is  available  to  the  simulation  controller  via  visual  interface  (not 
necessarily  through  the  network).  Based  on  the  battle  information  presented,  a  forward  observer 
enters  fire  missions  on  a  FED  and  sends  the  missions  to  the  battery  FDS  for  resource  allocation. 

The  FDS  then  communicates  with  the  MLRS/ATACMS  FCPT,  indicating  that  it  has  been 
assigned  a  mission. 

2.2.1  BATTLE  SIMULATION  to  FED  Forward  Observer  Operational  Concept 

The  forward  observer  views  the  battle  via  the  simulation  screens  for  a  simulation  application 
such  as  JANUS  or  CIMUL8.  Based  on  this  information,  a  Forward  Observer  determines  that  a 
call  for  fire  is  required.  The  FO  enters  the  call  for  fire  in  the  FED  and  issues  the  message  to  the 
battery  FDS. 

2.2. 1.1  Assumptions 

•  Communications  between  a  simulation  (i.e.,  JANUS)  and  the  Forward  Observer 
with  the  FED  are  not  on  the  network  but  are  visual  via  the  simulation's  user  interface  screens. 

•  Communications  between  the  Forward  Observer  and  the  simulation  providing 
battle  information  is  not  defined  in  this  document. 

•  The  integrated  system  may  be  used  without  simulation  battle  information  using 
predetermined  values. 
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2.2. 1.2 


Battle  Simulation  Actions 


The  purpose  of  the  battle  simulation  is  to  provide  battlefield  information  for  the  forward 
observer.  The  battle  simulation  may  also  provide  a  view  of  the  location  of  participating  entities 
based  on  received  network  information.  This  is  for  the  benefit  of  the  researcher  who  can 
determine  which  devices  are  present  and  what  actions  the  entities  are  performing.  In  the 
integrated  configuration  described  in  this  document,  the  simulation  is  not  required  to  send  DIS 
information  on  the  network.  The  battle  simulation  has  no  required  actions  relative  to  the  DIS 
network  although,  if  the  simulation  is  displaying  other  entities,  it  should  be  able  to  receive  DIS 
PDUs  from  the  network  for  display  purposes. 

2.2.1 .3  Forward  Observer/FED  Actions 

The  Forward  Observer  uses  the  battle  information  to  determine  which  fire  missions  should  be 
ordered.  The  Forward  Observer  may  also  enter  fire  missions  with  predetermined  values 
independent  of  a  battle  simulation.  These  missions  with  the  appropriate  information  are  entered 
into  the  FED. 


2.2.2  Forward  Observer  FED  to  FDS  Operational  Concept 

The  Forward  Observer,  having  entered  the  appropriate  fire  mission  into  the  FED,  transmits  the 
mission  to  the  FDS.  The  FDS,  upon  receipt  of  the  command  and  control  message  from  the  FED, 
shall  issue  the  appropriate  acknowledgment. 

2.2.2. 1  Assumptions 

•  FED  communications  with  the  FDS  will  be  in  the  form  of  command  and  control 
messages  containing  fire  missions  to  be  executed. 

•  FDS  communication  with  the  FED  will  be  in  the  form  of  acknowledgments  to 
command  and  control  messages  received  from  the  FED. 

2.2.2.2  FED  Actions 

The  FED  operator  transmits  the  command  and  control  message  requesting  a  particular  fire 
mission.  This  message  is  then  received  by  the  FED  PIU.  * 

2.2.2.3  FED  PIU  Actions 

When  the  FED  PIU  receives  the  call  for  fire  message  from  the  FED,  the  PIU  shall  create  and  send 
the  appropriate  DIS  PDUs  necessary  to  send  the  command  and  control  message  to  the  FDS. 
These  PDUs  are  sent  to  the  FDS  PIU. 

When  the  FED  PIU  receives  command  and  control  acknowledgments  from  the  FDS,  the  PIU  shall 
receive  and  interpret  the  DIS  PDUs.  The  PIU  shall  then  send  any  relevant  command  and  control 
information  to  the  FED. 
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2.2.2.4 


FDS  PIU  Actions 


When  the  FDS  PIU  receives  the  DIS  PDUs  from  the  FED  PIU,  it  receives  and  interprets  the  DIS 
PDUs.  It  then  sends  any  relevant  command  and  control  messages  to  the  FDS. 

When  the  FDS  sends  command  and  control  information  either  back  to  the  FED  or  to  the 
MLRS/ATACMS  FCPT,  the  FDS  PIU  receives  this  information  from  the  FDS,  creates  the 
proper  DIS  PDUs  for  sending  the  information,  and  sends  the  DIS  PDUs  onto  the  network  to  the 
proper  recipient. 

2.2.2.5  FDS  Actions 

Upon  receipt  of  the  command  and  control  information  from  the  FDS  PIU,  the  FDS  software 
receives  and  processes  the  command  and  control  message.  The  FDS  shall  then  issue  the 
appropriate  command  and  control  acknowledgment  to  the  FED.  This  ACK  is  sent  to  the  FED 
via  the  FDS  PIU. 

2.23  FDS  to  MLRS/ATACMS  FCPT  Operational  Concept 

The  operator  of  the  FDS  receives  the  fire  mission  from  the  FED  via  the  network  and  the 
associated  PIU's.  Displayed  is  information  concerning  die  mission  in  the  form  of  a  Call  For  Fire. 
The  operator  determines  the  resource  allocation  for  the  mission  (in  this  case,  the 
MLRS/ATACMS  FCPT)  and  sends  the  mission  on  to  MLRS/ATACMS  FCPT. 

2.2.3. 1  Assumptions 

•  FDS  communications  with  the  MLRS/ATACMS  FCPT  will  be  in  the  form  of  an 
MLRS  Call  For  Fire. 

•  MLRS/ATACMS  FCPT  communication  with  the  FDS  will  be  in  the  form  of 
acknowledgments  to  calls  for  fire,  response  messages,  and  launcher  status  reports. 

2.2.3 .2  FDS  Actions 

The  operator  of  the  FDS  shall  input  any  additional  information  required  concerning  the  fire 
mission  and  shall  process  target  information  received  from  the  FED.  When  ready,  the  operator 
transmits  the  ML^  Call  for  Fire  command  and  control  message. 

2 .2.3 . 3  FDS  PIU  Actions 

Upon  receiving  the  Call  for  Fire  message  from  the  FDS,  the  PIU  shall  create  and  send  the  proper 
DIS  PDUs  in  order  to  send  the  command  and  control  information  to  the  MLRS/ATACMS 
FCPT. 

The  FDS  PIU  shall  also  be  able  to  receive  DIS  PDUs  with  TACFIRE  information  relevant  to  the 
FDS.  These  PDUs  contain  TACFIRE  information  from  the  launcher  concerning  launcher  status 
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and  acknowledgments  to  FDS  issued  calls  for  fire.  The  PIU  shall  process  the  DIS  PDUs  and 
issue  the  TACFIRE  data  to  the  FDS. 

2.2.3.4  MLRS/ATACMS  FCPT  Actions 

Upon  receipt  of  DIS  PDUs  from  the  FDS  PIU,  the  MLRS/ATACMS  FCPT  network  interface 
shall  process  the  DIS  PDUs  and  send  the  command  and  control  information  on  to  the 
MLRS/ATACMS  FCPT  software.  The  MLRS/ATACMS  FCPT  software  shall  then  process 
the  received  command  and  control  information  and  take  appropriate  actions  to  present  the 
information  to  the  FCP  trainee. 

In  response  to  the  receipt  of  the  command  and  control  messages,  the  MLRS/ATACMS  FCPT 
shall  issue  appropriate  acknowledgments  to  the  FDS.  In  addition,  the  MLRS/ATACMS  FCPT 
shall  issue  a  message  responding  to  the  Call  for  Fire  (e.g.  WILCO).  The  MLRS/ATACMS  FCPT 
network  interface  shall  create  and  issue  the  appropriate  DIS  PDUs  for  sending  out  command  and 
control  message  ACK's  and  launcher  status  reports  as  required. 

2.2.4  MLRS/ATACMS  FCPT  to  DIS  Network  Operational  Concept 

The  operator  of  the  MLRS/ATACMS  FCPT  receives  the  fire  mission  from  the  FDS  via  the  FDS 
PIU,  &e  network  and  the  MLRS/ATACMS  FCPT  network  interface.  The  operator  carries  out 
the  mission  and  the  weapon  is  fired. 

2.2.4. 1  Assumptions 

•  Entity  State  PDUs  are  issued  for  the  launcher  carrier  vehicle. 

•  Fire,  Detonation,  and  appropriate  Entity  State  PDUs  are  issued  for  the  munition 

fired. 

2.2.4.2  MLRS/ATACMS  FCPT  Actions 

The  MLRS/ATACMS  FCPT  shall  simulate  the  munitions  fired  by  the  MLRS/ATACMS  FCPT. 
This  simulation  shall  include  representation  of  the  firing,  trajectory,  and  detonation  of  the 
munition.  A  Fire  PDU  shall  be  issued  when  the  MLRS/ATACMS  FCPT  is  fired.  In  addition,  a 
Detonation  PDU  shall  be  sent  upon  munition  detonation. 

Entity  State  PDUs  shall  also  be  issued  representing  the  MLRS/ATACMS  FCPT's  launcher 
carrier  vehicle. 

23  INTEGRATED  SYSTEM  USE  WITH  SPECT8/CIMUL8/DISIP8 

The  integrated  use  of  the  system  using  SPECT8/CIMUL8/DISIP8  to  provide  command  and 
control  events  to  the  network  replaces  the  use  of  the  FED  with  CIMUL8.  This  provides  a 
simulation  generated  event  into  the  networked  system  instead  of  FED  equipment  generated 
events.  The  operator  of  the  SPECT8/CIMUL8/DISIP8  system  enters  the  appropriate  events  for 
use  in  the  simulation  experiment.  When  the  experiment  begins,  the  entity  information  is 
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generated  by  SPECT8/CIMUL8/DISIP8  and  sent  to  the  DIS  network  in  the  form  of  DIS  PDUs. 
Command  and  control  events  are  simulated  within  SPECT8/CIMUL8/DISIP8  and  communicated 
to  the  FDS  through  an  FR  GRID  command  and  control  message.  The  FDS  then  processes  the 
message  as  described  in  2.2  and  sends  the  appropriate  Call  For  Fire  to  the  FCPT. 

The  operator  of  the  MLRS/ATACMS  FCPT,  upon  receiving  command  and  control  information 
from  the  FDS  will  carry  out  the  appropriate  actions. 

2.3.1  Assumptions 

•  SPECT8/CIMUL8/DISIP8  communication  with  the  FDS  will  be  in  the  form  of 
FR  GRID  messages. 

*  MLRS/ATACMS  FCPT  does  not  communicate  with  CIMUL8  but 
communicates  with  the  FDS  as  described  in  2.2. 

2.3.2  SPECT8/CIMUL8/DISIP8  Actions 

When  the  SPECT8/CIMUL8/DISIP8  simulation  application  is  ready  to  send  the  FR  GRID 
message,  it  shall  create  the  proper  command  and  control  message  for  use  by  the  FDS.  This 
command  and  control  message  shall  be  sent  onto  the  DIS  network  using  the  appropriate  DIS 
PDUs. 

Although  ACK's  will  be  sent  to  SPECT8/CIMUL8/DISIP8  from  the  FDS  upon  receipt  of  the  FR 
GRID,  SPECT8/CIMUL8/DISIP8  is  not  required  to  process  these  messages. 

2.3.3  MLRS/ATACMS  FCPT  Actions 

See  section  2.2.4.2  for  MLRS/ATACMS  FCPT  Actions. 

3.0  INTEGRATED  SYSTEM  INTERFACE  DETAILS 

This  section  contains  the  details  for  implementing  the  integrated  system  interfaces  described  in 
Section  2.  These  interfaces  can  be  described  using  the  International  Organization  for 
Standardization  (ISO)  Open  Systems  Interconnection  (OSI)  Reference  Model.  The  OSI 
Reference  Model  with  the  protocol  selection  for  our  integrated  system  is  shown  in  Figure  C-2. 

3.1  NETWORK  INTERFACE  REQUIREMENTS 

The  following  interface  requirements  apply  to  all  devices  that  are  part  of  the  integrated  system. 

3.1.1  Physical  and  Link  Layers  -  Ethernet  Network 

All  devices  shall  support  an  interface  to  an  Ethernet  (not  IEEE  802.3)  network.  This  includes 
utilization  of  the  Ethernet  physical  and  data  link  layer  protocols.  The  addressing  mode  for 
sending  information  shall  be  broadcast. 
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-  This  is  where  CIMUL8,  FED, 
FDS,  MLRS  FCPT  fit  in 


-  DIS  PDUs  provide  the  vehicle 
to  transmit  simulation  info 

-  Standard  Network  services 
Provided  by  IIDP/IP 

-  Ethernet  Provides  Medium 
for  Network 


-  10-Base  T  wiring 

Network 


Figure  C-2.  Integrated  system  layers. 

Octet  ordering  shall  conform  to  the  DIS  standard  of  little  endian. 

The  physical  media  for  Ethernet  shall  be  10-BaseT  cabling.  This  cabling  shall  be  attached  to  the 
Ethernet  concentrator. 

This  network  hardware  configuration  is  illustrated  in  Figure  C-3.  Figure  C-4  shows  the  peer-to- 
peer  communications  established  by  the  requirements  of  3. 1 . 1 . 

3.1.2  Network  and  Transport  Layer 

All  devices  on  the  network  shall  utilize  UDP/IP  as  specified  by  the  CADIS  1.0  standard. 

3.1.3  Session,  Presentation,  and  Application  Layer 

All  devices  <ghall  utilize  the  DIS  PDU  standard  as  specified  in  version  2.0.3.  Table  C-3  shows 
which  of  the  devices  on  the  network  are  required  to  support  which  PDUs. 


Simulation  Application 


Appl  Layer  -  DIS 
Pres  Layer  -  DIS 
Sess  Layer  -  DIS 

Trans  Layer  -  UDP 
Net  Layer  -  IP 
Link  Layer  -  Ethernet 
Phys  Layer  -  Ethernet 
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sical  and  link  layer  communications. 
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Table  C-1.  IP  Header  Information 


Internet  Protocol  shall  be  implemented  with  the  following  header  values: 


IP  Header  Field 

Bit  Numbers 

Field  Value 

Version 

1-3 

Header  Length 

4-7 

Service  Type 

8-15 

0 

Total  Length 

16-31 

r4^(Hdr  Len)  +  UDP  packet  lenl 

Identification 

32-47 

N+1 

Flags 

48-50 

0 

Fragment  Ofl&et 

51-63 

0 

(packets  not  fragmented) 

Time  to  Live 

64-71 

60 

Protocol 

72-79 

Header  Checksum 

80-95 

Source  IP  Address 

96-127 

. . . 

Destination  IP  Address 

128-159 

Options  (if  any) 

N/A 

N/A 

♦♦Address  Resolution  Protocol  (ARP)  is  not  required  for  this  application. 


Table  C-2.  UDP  Header  Information 
The  UDP  header  shall  contain  the  following  values: 


UDP  Header  Field 

Bit  Numbers 

Field  Value 

UDP  Source  Port 

0-15 

3000 

Destination  Port 

16-31 

3000 

Total  Length 
(in  octets) 

32-47 

8  +  length  of  PDU 

UDP  Checksum 

48-63 

0 

(Checksum  not  used) 

Table  C-3.  PDU  Requirement  Sunmiary. 


PDUs  Issued 

PDUs  Processed 

Device 

ES* 

Fire 

Det 

Tran 

Sig 

ES 

Fire 

Det 

Tran 

Sig 

CIMUL8 

X 

X 

X 

X 

X 

X 

X 

FED 

X 

X 

X 

X 

X 

X 

FDS 

X 

X 

X 

X 

X 

X 

MLRSFCP 

X 

X 

X 

X 

X 

X 

X 

X 

♦Key:  ES  -  Entity  State  PDU  Det  -  Detonation  PDU  Sig  -  Signal  PDU  Fire -Fire  PDU  Tran  -  Transmitter  PDU 
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Figure  C-5  shows  the  peer-to-peer  communications  established  by  the  requirements  of  3.1.2. 


i 

to! 

ill 

Peer  Comm 

IMMWMIBWiillHi 

Trans  Layer  -  UDP 

Trans  Layer  -  UDP 

Net  Layer  -  IP 

Net  Layer  -  IP 

Network 

Figure  C-5.  Network  and  transport  layer  communications. 

Requirements  related  to  these  PDUs  are  described  in  the  subparagraphs  that  follow. 

3. 1.3.1  Entity  State  PDU 

The  Entity  State  PDU  shall  be  issued  by  all  simulation  applications  to  carry  entity  information 
pertaining  to  the  entity  that  is  issuing  command  and  control  information  on  the  network.  This 
PDU  shall  be  issued  in  accordance  with  the  DIS  PDU  standard  version  2.0.3.  The  default  time 
for  sending  the  Entity  State  PDU  is  five  (5)  seconds.* 

The  Entity  State  PDU  shall  be  processed  by  simulation  applications  that  require  the  information 
for  entity  representation  on  the  network. 

3.1.3.2  Fire  PDU 

The  Fire  PDU  shall  be  issued  by  the  MLRS/ATACMS  FCPT  when  the  launcher  has  fired  a 
rocket  or  missile.  For  this  application,  the  MLRS  shall  fire  rockets. 

The  Fire  PDU  shall  be  processed  by  simulation  applications  that  require  the  information  for 
entity  representation  on  the  network.  None  of  the  devices  on  the  integrated  network  are 
currently  required  to  interpret  Fire  PDUs. 


The  MLRS/ATACMS  FCPT  does  not  conform  to  the  5-second  rule.  It  sends  an  Entity  State  PDU  when  it 
comes  on  line,  when  it  begins  to  move  to  a  firing  point,  and  when  it  arrives  at  a  firing  point. 


51 


3.1.3.3 


Detonation  PDU 


The  Detonation  PDU  shall  be  issued  by  the  MLRS/ATACMS  FCPT  when  the  rocket  launched 
impacts  or  detonates. 

The  Detonation  PDU  shall  be  processed  by  all  simulation  applications  on  the  network  to 
determine  if  the  entity  represented  by  the  device  has  been  affected  by  incoming  fires.  The 
Detonation  PDU  may  also  be  processed  by  simulation  applications  that  require  the  information 
for  visual  representation  of  the  detonation.  Processing  for  visual  representation  is  currently  done 
only  by  CIMUL8. 

3.1. 3.4  Transmitter  PDU 

The  Transmitter  PDU  shall  be  issued  by  all  simulation  applications  on  the  network  when  sending 
command  and  control  information.  The  Transmitter  PDU  shall  be  used  to  cany  information 
concerning  the  radio  that,  in  the  real  world,  would  be  used  to  carry  the  command  and  control 
messages.  This  PDU  is  issued  prior  to  its  associated  Signal  PDU  and  after  sending  its  associated 
Signal  PDU. 

The  Transmitter  PDU  shall  be  processed  by  all  devices  on  the  network  receiving  command  and 
control  information. 

3.1.3.5  Signal  PDU 

The  Signal  PDU  shall  be  issued  by  all  simulation  applications  to  carry  the  command  and  control 
messages  on  the  network.  This  PDU  shall  be  issued  after  the  initial  Transmitter  PDU  with  the 
simulated  transmitting  radio  information  has  been  issued. 

The  Signal  PDU  shall  be  processed  by  all  simulation  applications  on  the  network  receiving 
command  and  control  information. 

Figure  C-6  shows  the  peer-to-peer  communications  established  by  the  requirements  of  3.1.3. 


52 


AppI  Layer  -  DIS 

Peer  Comm 

Appl  Layer  -  DIS 

Pres  Layer  -  DIS 

Pres  Layer  -  DIS 

Sess  Layer  -  DIS 

Sess  Layer  -  DIS 

mSI 

.sidaiifctoi 

Network 

Figure  C-6.  Session,  presentation,  &  application  layer  communications. 

3.2  SIMULATION  APPLICATIONS  INTERFACES 

This  section  describes  the  details  of  the  simulation  application  interface  between  various 
components  of  the  integrated  network.  The  exchange  of  command  and  control  information  is 
accomplished  using  the  appropriate  command  and  control  messages.  Simulation  Application 
communications  are  illustrated  in  Figure  C-7. 

3.2.1  Interface  From  SPECT8/CIMUL8/DISIP8  To  MLRS/ATACMS  FCPT 

The  simulation  application  to  which  SPECT8/CIMUL8/DISIP8  will  be  connected  is  the 
MLRS/ATACMS  FCPT. 

3.2.1. 1  Messages  From  SPECT8/CIMUL8/DISIP8 

Communications  between  SPECT8/CIMUL8/DISIP8  and  the  FDS  shall  be  accomplished  using 
the  FR  GRID  message,  typically  sent  by  the  FED.  The  FR  GRID  message  shall  be  used  to 
transmit  fire  mission  information  from  SPECT8/CIMUL8/DISIP8  to  the  FDS.  Although  the 
FDS  will  issue  acknowledgment  messages  to  FR  GRID  messages  sent  by 
SPECT8/CIMUL8/DISIP8,  SPECT8/CIMUL8/DISIP8  is  not  required  to  process  them. 
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Figure  C-7.  Simulation  application  communications. 

3.2.1. 2  Messages  from  MLRS/ATACMS  FCPT  to  FDS 

The  MLRS/ATACMS  FCPT  is  responsible  for  sending  a  response  to  the  FDS  issued  Call  For 
Fire  (CFF)  messages.  This  response  shall  be  in  the  form  of  a  Will  Comply  message  (WILCO). 
The  MLRS/ATACMS  FCPT  is  also  required  to  send  launcher  status  as  necessary. 

The  MLRS/ATACMS  FCPT  will  NOT  send  acknowledgment  messages  to  the  FDS.  It  is 
therefore  up  to  the  PIU  to  provide  the  FDS  the  proper  ACK  message  to  satisfy  the  FDS 
communications  software. 

3.2.2  Interface  Between  FED  and  FDS 

The  simulation  application  FED  has  a  logical  interface  to  the  battery  FDS.  The  FED  transmits 
target  information  to  the  FDS. 
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3.2.2.1 


Messages  from  FED  to  FDS 


Communications  from  the  FED  to  the  FDS  shall  be  accomplished  using  the  FED  FOCC 
command  and  control  messages.  The  FED  shall  be  able  to  issue  the  following  messages:^ 

1.  FRGRID 

This  message  is  used  to  initiate  a  fire  request  by  reporting  target  location  using  grid 

coordinates. 


2.  FOCMD 

This  message  is  used  by  an  observer  to  report  changes  in  fire  mission  commands. 
Also  used  by  firing  units  to  report  firing  status. 

3.  Freetext  Message 

This  message  is  used  to  send  text  messages  to  command  and  control  devices.  For 
our  system,  we  used  the  Freetext  message  to  test  interface  between  devices. 

In  addition,  the  FED  shall  also  be  capable  of  receiving  the  resulting  acknowledgments  and  status 
reports  issued  by  the  FDS.  These  messages  are  described  in  3.2.2.2. 

3.2.2.2  Messages  from  FDS  to  FED 

The  FDS  is  responsible  for  providing  the  FED  FO  or  FIST  with  acknowledgments  to  transmitted 
messages  as  well  as  status  reports  as  required.  Communications  from  the  FDS  to  the  FED  shall 
be  accomplished  using  FDS  command  and  control  messages.  This  interface  shall  support  the 
following  messages; 

1.  Acknowledge  Message 

These  are  automatically  generated  by  the  FDS  when  it  receives  a  message  from  the 

FED. 


2.MTO 

The  MTO  is  automatically  generated  by  the  FDS  after  an  MLRS  CFF  has  been 
sent  to  the  FCPT.  This  may  be  transmitted  back  to  Ae  FO  or  FIST  if  desired  but  it  is  not 
required. 


The  interface  developed  will  support  any  message  that  the  FED  is  capable  of  sending.  Restriction  on  which 
message  can  be  used  with  this  interface  is  dependent  on  which  messages  sent  by  the  FED,  are  capable  of  being 
received  by  the  FDS.  During  development,  FR  GRID,  FO  CMD,  and  Free  Text  messages  were  used. 
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3. Free  text  Messages 

TMs  message  is  used  to  send  text  messages  to  command  and  control  devices.  For 
our  system,  we  used  the  Freetext  message  to  test  interface  between  devices. 

In  addition,  the  FDS  shall  also  be  capable  of  receiving  the  command  and  control  messages  issued 
by  the  FED.  These  messages  are  described  in  3.2.2. 1. 

3.2.3  Interface  From  FDS  To  MLRS/ATACMS  FCPT 

The  simulation  application  to  which  the  FDS  will  be  coimected  is  the  MLRS/ATACMS  FCPT. 

3.2.3. 1  Messages  From  FDS  to  MLRS/ATACMS  FCPT 

Communications  between  the  battery  FDS  and  the  FCPT  shall  be  accomplished  using  the  battery 
FDS  to  MLRS  Launcher  interface  messages.  Of  these  messages,  the  FDS  shall  be  capable  of 
issuing  the  MLRS;CFF  (call  for  fire).  The  MLRS;CFF  message  shall  be  used  to  transmit  a  fire 
mission  fi-om  the  battery  FDS  to  the  MLRS/ATACMS  FCPT. 

The  FDS  shall  also  be  able  to  receive  response  messages  and  status  reports  issued  by  the 
MLRS/ATACMS  FCPT.  These  messages  are  described  in  3.2.1. 2. 

3.2.3.2  Messages  from  MLRS/ATACMS  FCPT  to  Battery  FDS 

The  MLRS/ATACMS  FCPT  is  required  to  send  a  response  message  to  the  FDS  command  and 
control  message  MLRS;CFF.  The  FCPT  is  also  responsible  to  send  launcher  status  as  necessary. 
The  MLRS/ATACMS  FCPT  will  currently  not  be  responsible  for  sending  the  ACK  to  the  FDS 
in  response  to  the  MLRS;CFF  messages.  Therefore,  the  MLRS/ATACMS  FCPT  shall  be 
capable  of  issuing  the  following: 

1.  AFU;UPDATE 

The  AFU;UPDATE  message  shall  be  used  to  report  fire  unit  status  information  to 

the  FDS. 


2.  MLRS;RESPON 

The  MLRS;RESPON  message  shall  be  sent  by  the  MLRS/ATACMS  FCPT  when 
a  call  for  fire  (MLRS;CFF)  is  received.  This  message  contains  a  response  of  WILCO  (Will 
Comply). 

In  addition,  the  MLRS/ATACMS  FCPT  shall  be  able  to  receive  the  command  and  control 
messages  issued  by  the  battery  FDS.  These  messages  are  described  in  3.2.3. 1. 
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APPENDIX  D 
PROTOCOL  DATA  UNITS 
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PROTOCOL  DATA  UNITS 


1.0  Entity  State  PDU 

The  Entity  State  PDU  shall  was  issued  by  all  simulations  participating  on  the  integrated 
network.  These  PDUs  shall  represent  the  entities  that  are  carrying  the  radio  devices  that 
traditionally  issue  the  command  and  control  message  in  the  real  world  use  of  the  device.  Since 
entity  movement  is  not  supported  for  a  number  of  the  devices,  these  devices  will  issue  Entity 
State  PDUs  once  every  5  seconds,  according  to  the  default  value  established  in  the  standard. 
Dead  reckoning  will  not  be  performed  for  these  same  entities.  CIMUL8,  which  does  represent 
entity  movement,  shall  implement  dead  reckoning  and  issue  Entity  State  PDUs  that  are  dictated 
by  the  Dead  Reckoning  algorithm  in  use.  The  following  subparagraphs  describe  the  values  that 
should  be  used  in  the  issue  of  Entity  State  PDUs: 

1.1  CIMUL8  Entity  State  PDUs 

When  CIMUL8  is  used  in  the  maimer  described  in  Section  2  of  this  document,  it  will  be 
representing  a  Forward  Observer  with  a  Forward  Entry  Device.  For  this  entity,  it  shall  issue 
Entity  State  PDUs  with  the  following  field  values: 


IBSSH 

PDU  FIELDS 

FIELD 

VALUE 

Protocol  Version  -  8-bit  enumeration 

3  (version  2.0.3) 

Exercise  ED  -  8-bit  unsigned  integer 

100 

PDU 

PDU  Type  -  8-bit  enumeration 

1  (ES  PDU) 

96 

HEADER 

Padding  -  8  bits  unused 

0 

Time  Stamp  -  32-bit  unsigned  integer 

Relative  timestamp 
assigned  by  application 

Length  -  16-bit  unsigned  integer 

Padding  - 16  bits  unused 

0 

Site  -  16-bit  unsigned  integer 

100 

48 

ENTITY  ED 

Application  -  16-bit  unsigned  integer 

Entity  -  16-bit  unsigned  integer 

Assigned  by  CIMUL8 

8 

FORCE  ID 

8-bit  enumeration 

1  (friendly) 

8 

#  OF  ARTICULATION 
PARAMETERS 

8-bit  unsigned  integer 

0 

(No  articulated  parts) 

Entity  Kind  -  8-bit  emuneration 

3  (lifeform) 

Domain  -  8-bit  enumeration 

1  (land) 

ENTITY 

Country  -  16-bit  enumeration 

225  (USA) 

64 

TYPE 

Category  -  8-bit  enumeration 

Subcategory  -  8-bit  enumeration 

Specific  -  8-bit  enumeration 

1  (single  entity) 

Extra  -  8-bit  enumeration 

0  (unused) 
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ALTERNATE 

ENTITY 

TYPE 


ENTITY  LOCATION 


ENTITY  STATE  PDU  FIELDS  (cont) 


Entity  Kind  -  8-bit  enumeration 


Domain  -  8-bit  enumeration 


Country  -  16-bit  enumeration 


Category  -  8-bit  enumeration 


Subcategoiy  -  8-bit  enumeration 


Specific  -  8-bit  enumeration 


Extra  -  8-bit  enumeration 


X-Component  -  64-bit  floating  point 


Y-Component  -  64-bit  floating  pomt 


Z-Component  -  64-bit  floating  point 


X-Component  -  32-bit  floating  point 


Y-Component  -  32-bit  floating  point 


Z-Component  -  32-bit  floating  point 


Psi  -  32-bit  floating  point 


Theta  -  32-bit  floating  point 


Phi  -  32-bit  floating  point 


32-bit  record  of  enumerations 


Bit  0  -  Paint  Scheme 


Bit  1  -  Mobility  Kill 


Bit  2  -  Fire  Power  Kill 


Bits  3-4  -  Damage 


Bits  7-8  -  Trailing  Effects 


Bits  9-11  -  Hatch 


Bits  12-14  -  Lights 


Bit  15  -  Flamin 


FIELD 

VALLfE 


3  (lifefoim) 


1  (land) 


225  (USA) 


1  (dismounted  infantry) 


6(M-60) 


1  (single  entity) 


0  (unused) 


assigned  by 
application 


assigned  by 
application 


assigned  by 
application 


0  (not  moving) 


0  (not  moving) 


0  (not  moving) 


assigned  by  application 


assigned  by  application 


assigned  by  application 


(see  below) 


1  (camouflage) 


0  (no  mobility  kill) 


0  (No  fire  power  kill) 


0  (no  damage) 
or 

3  (destroyed-  -if  det 
PDU  received  for 
location) 


0  (not  smoking) 
or 

1  (smoke  plume  -  if 
smoke  part  of 
destroved  appearance) 
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ENTITY  STATE  PDU  FIELDS  (cont) 

FIELD 

VALUE 

32 

ENTITY 

Bit  16  -  Launcher 

0  (not  raised) 

(not  applicable) 

(continued) 

APPEARANCE 

Bits  17-18  -  Camouflage  Type 

0  (Desert  camouflage) 

(continued) 

Bit  19  -  Concealment 

0  (not  concealed) 

Bits  20-23 

0  (unused) 

Bits  24-31  -  Entity  Specific 

0  (unused) 

Dead  Reckoning  Algorithm  -  8  bit  enumeration 

selected  by  CIMUL8 

DEAD 

other  Parameters  - 120  bits  unused 

0  (unused) 

320 

RECKONING 

PARAMETERS 

Entity  Linear  Acceleration  -  3x32-bit  floating 
points 

0,  0,  0  (not 
accelerating) 

Entity  Angular  Velocity  -  3x32-bit  floating  points 

0,  0,  0  (not  rotating) 

Character  set  -  8-bit  enumeration 

0  (unused) 

96 

ENTITY  MARKING 

1 1  -  8-bit  unsigned  integers 

11x0  (not  used) 

32 

CAPABILITIES 

32  Boolean  Fields 

all  fields  =  0 
(no  capabilities) 

Entity  state  PDUs  for  other  CIMULS  generated  entities  shall  be  generated  in  the  format  required 
for  those  entities.  Field  values  are  selected  by  CIMULS  within  the  guidelines  provided  in  the 
DIS  PDU  2.0.3  Standard. 
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12  FED  Entity  State  PDUs 


When  the  FED  is  used  in  the  manner  described  in  Section  2  of  this  document,  it  shall  issue  Entity 
State  PDUs  with  the  following  field  values: 


FIELD 
SIZE  (bits') 

PDU  FIELDS 

FIELD 

VALUE 

Protocol  Version  -  8-bit  enumeration 

3  (version  2.0.3) 

Exercise  ID  -  8-bit  unsigned  integer 

PDU 

PDU  Type  -  8-bit  enumeration 

96 

HEADER 

Padding  -  8  bits  unused 

0 

Time  Stamp  -  32-bit  unsigned  integer 

Relative  timestamp 
assigned  by  application 

Length  -  16-bit  imsigned  integer 

144  (bytes) 

Padding  - 16  bits  unused 

0 

Site  -  16-bit  unsigned  integer 

100 

48 

ENTITY  ID 

Application  -  16-bit  unsigned  integer 

100  (FED) 

Entity  -  16-bit  unsigned  integer 

1 

$ 

FORCE  ID 

8-bit  enumeration 

1  (friendly) 

8 

#  OF  ARTICULATION 
PARAMETERS 

8-bit  unsigned  integer 

0  (No  articulated  parts) 

Entity  Kind  -  8-bit  enumeration 

3  (lifeform) 

Domain  -  8-bit  enumeration 

1  (land) 

ENTITY 

Country  -  16-bit  enumeration 

225  (USA) 

64 

TYPE 

Category  -  8-bit  enumeration 

1  (dismounted  infantry) 

Subcategory  -  8-bit  enumeration 

Specific  -  8-bit  enumeration 

Extra  -  8-bit  enumeration 

0  (imused) 

Entity  Kind  -  8-bit  enumeration 

3  (lifeform) 

Domain  -  8-bit  enumeration 

1  (land) 

ALTERNATE 

Country  -  16-bit  enumeration 

225  (USA) 

64 

ENTITY 

Category  -  8-bit  enumeration 

1  (dismounted  infantry) 

TYPE 

Subcategory  -  8-bit  enumeration 

Specific  -  8-bit  enumeration 

1  (single  entity) 

Extra  -  8-bit  enumeration 

0  (unused) 

X-Component  -  64-bit  floating  point 

assigned  by  application 

192 

ENTITY  LOCATION 

Y-Component  -  64-bit  floating  point 

assigned  by  application 

Z-Component  -  64-bit  floating  point 

assigned  by  application 

ENTITY 

X-Component  -  32-bit  floating  point 

0  (not  moving) 

96 

LINEAR 

Y-Component  -  32-bit  floating  point 

0  (not  moving) 

VELOCITY 

Z-Component  -  32-bit  floating  point 

0  (not  moving) 
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RECKONING 

PARAMETERS 


ENTITY 


MARKING 


CAPABILITIES 


ENTITY  STATE  PDU  FIELDS  (cont) 


Psi  -  32-bit  floating  point 


Theta  -  32-bit  floating  point 


Phi  -  32-bit  floating  point 


32-bit  record  of  enumerations 


Bit  0  -  Paint  Scheme 


Bit  1  -  Mobility  Kill 


Bit  2  -  Fire  Power  Kill 


Bits  3-4  -  Damage 


Bits  5-6  -  Smoke 


Bits  7-8  -  Trailing  Effects 


Bits  9-1 1  -  Hatch 


Bits  12-14  -  Lights 


Bit  15  -  Flaming 


Bit  16  -  Life  Form  State 


Bit  17  -  Weapon  1  State 


Bit  18  -  Weapon  2  State _ 


Bits  19-23 


Bits  24-31  -  Entity  Specific  _ 


Dead  Reckoning  Algorithm  -  8  bit  enumeration 


Other  Parameters  - 120  bits  unused 


Entity  Linear  Acceleration  -  3x32-bit  floating  points 


Entity  Angular  Velocity  -  3x32-bit  floating  points 


Character  set  -  8-bit  enumeration 


1 1  -  8-bit  unsigned  integers _ 


32  Boolean  Fields 


FIELD 

VALUE 


assigned  by  application 


assigned  by  application 


assigned  by  application 


1  (camouflage) 


0  (no  mobility  kill) 


0  (No  fire  power  kill) 


0  (no  damage) 
or 

3  (destroyed-  -if  det 
PDU  received  for 
location) 


0  (not  smoking) 


0  (none) 


0  (not  applicable) 


0  (none) 


0  (none) 


0  (stowed) 


0  (stowed) 


0  (unused) 


0  (unused) 


1  (static) 


0 (unused) 


0  (unused) 


11x0  (unused) 


32  X  0  (no  capabilities) 
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1.3  FDS  Entity  State  PDUs 


When  FDS  is  used  in  the  manner  described  in  Section  2  of  this  document,  it  shall  issue  Entity 
State  PDUs  with  the  following  field  values: 


■aiisiiiH 

BBSKIfTlSi 

PDU  FIELDS 

FIELD 

VALUE 

Protocol  Version  -  8-bit  enumeration 

3  (version  2.0.3) 

Exercise  ED  -  8-bit  unsigned  integer 

100 

PDU 

PDU  Type  -  8-bit  enumeration 

1  (ES  PDU) 

96 

HEADER 

Padding  -  8  bits  unused 

0 

Time  Stamp  -  32-bit  unsigned  integer 

Relative  timestamp 
assigned  by  application 

Length  -  16-bit  unsigned  integer 

144  (bytes) 

Padding  -  16  bits  unused 

0 

Site  -  16-bit  unsigned  integer 

100 

48 

ENTITY  ID 

Application  -  16-bit  unsigned  integer 

200  (FDS) 

Entity  -  16-bit  unsigned  integer 

1 

8 

FORCE  ID 

8-bit  enumeration 

1  (fiiendly) 

8 

#  OF  ARTICULATION 
PARAMETERS 

8-bit  unsigned  integer 

0 

(No  articulated  parts) 

Entity  Kind  -  8-bit  enumeration 

1  (Platform) 

Domain  -  8-bit  enumeration 

1  (Land) 

ENTITY 

Country  -  16-bit  enumeration 

225  (USA) 

64 

TYPE 

Category  -  8-bit  enumeration 

6  (Util  veh) 

Subcategory  -  8-bit  enumeration 

1  (HMMWV) 

Specific  -  8-bit  enumeration 

0  (unused) 

Extra  -  8-bit  enumeration 

0  (unused) 

Entity  Kind  -  8-bit  enumeration 

1  (Platform) 

Domain  -  8-bit  enumeration 

1  (Land) 

ALTERNATE 

Country  -  16-bit  enumeration 

225  (USA) 

64 

ENTITY 

Category  -  8-bit  enumeration 

6  (Util  veh) 

TYPE 

Subcategory  -  8-bit  enumeration 

1  (HMMWV) 

Specific  -  8-bit  enumeration 

0  (unused) 

Extra  -  8-bit  enumeration 

0  (unused) 

X-Component  -  64-bit  floating  point 

assigned  by  application 

192 

ENTITY  LOCATION 

Y-Component  -  64-bit  floating  point 

assigned  by  application 

Z-Component  -  64-bit  floating  point 

assigned  by  application 

ENTITY 

X-Component  -  32-bit  floating  point 

0  (not  moving) 

96 

LINEAR 

Y-Component  -  32-bit  floating  point 

0  (not  moving) 

VELOCITY 

Z-Component  -  32-bit  floating  point 

0  (not  moving) 
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ENTITY  STATE  PDU  FIELDS  (cont) 


Psi  -  32-bit  floating  point 


Theta  -  32-bit  floating  point 


Phi  -  32-bit  floating  point 


32-bit  record  of  enumerations 


Bit  0  -  Paint  Scheme 


Bit  1  -  Mobility  Kill 


Bit  2  -  Fire  Power  Kill 


Bits  3-4  -  Damage 


RECKONING 

PARAMETERS 


ENTITY 


MARKING 


CAPABILITIES 


Bits  7-8  -  Trailing  Effects 


Bits  9-1 1  -  Hatch 


Bits  12-14  -  Lights  _ 


Bit  15  -  Flaming  _ 


Bit  16  -  Launcher 


Bits  17-18  -  Camouflage  Type 


Bit  19  -  Concealment 


Bits  20-23 


Bits  24-31  -  Entity  Specific _ 


Dead  Reckoning  Algorithm  -  8  bit  enumeration 


Other  Parameters  -  120  bits  unused 


Entity  Linear  Acceleration  -  3x32-bit  floating 

points _ 


Entity  Angular  Velocity  -  3x32-bit  floating  points 


Character  set  -  8-bit  enumeration 


11  -  8-bit  unsigned  integers 


32  Boolean  Fields 


FIELD 

VALUE 


assigned  by  application 


assigned  by  application 


assigned  by  application 


1  (camouflage) _ 


0  (no  mobility  kill) 


0  (No  fire  power  kill) 


0  (no  damage) 
or 

3  (destroyed-  -if  det 
PDU  received  for  location 


0  (not  smoking) 
or 

1  (smoke  plume  -  if 
smoke  part  of 
destroyed  aoDearance) 


0  (none) 


0  (not  applicable) 


0  (none) 


0  (none)  _ 


0  (not  raised) 
(not  applicable) 


0  (Desert  camouflage) 


0  (not  concealed) 


0  (unused) 


0  (unused) 


1  (static) 


0  (unused) 


0,0,0  (not  accelerating) 


0,0,0  (not  rotating) _ 


0  (unused) 


11x0  (unused) 


32  X  0  (no  capabilities) 
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1.4  MLRS/ATACMS  FCPT  Entity  State  PDUs 


When  the  MLRS/ATACMS  FCPT  is  used  in  the  manner  described  in  Section  2  of  this  document, 
it  shall  issue  Entity  State  PDUs  with  the  following  field  values: 


ISBisIiStISI 

PDU  FIELDS 

FIELD 

VALUE 

Protocol  Version  -  8-bit  enumeration 

3  (version  2.0.3) 

Exercise  ID  -  8-bit  unsigned  integer 

100 

PDU 

PDU  Type  -  8-bit  enumeration 

1  (ES  PDU) 

96 

HEADER 

Padding  -  8  bits  imused 

0 

Time  Stamp  -  32-bit  imsigned  integer 

Relative  timestamp 
assigned  by  application 

Length  -  16-bit  unsigned  integer 

144  (bytes) 

Padding  -  16  bits  unused 

0 

Site  -  16-bit  unsigned  integer 

100 

48 

ENTITY  ID 

Application  -  16-bit  unsigned  integer 

400  (  MLRS  FCPT) 

Entity  -  16-bit  unsigned  integer 

1 

8 

FORCE  ID 

8-bit  enumeration 

1  (friendly) 

8 

#  OF  ARTICULATION 
PARAMETERS 

8-bit  unsigned  integer 

0 

(No  articulated  parts) 

Entity  Kind  -  8-bit  enumeration 

1  (Platform) 

Domain  -  8-bit  enumeration 

1  (Land) 

ENTITY 

Country  -  16-bit  enumeration 

225  (USA) 

64 

TYPE 

Category  -  8-bit  enumeration 

4  (Self-prop  artillery) 

Subcategory  -  8-bit  enumeration 

1  (MLRS) 

Specific  -  8-bit  enumeration 

0  (unused) 

Extra  -  8-bit  enumeration 

0  (unused) 

Entity  Kind  -  8-bit  enumeration 

1  (Platform) 

Domain  -  8-bit  enumeration  | 

1  (Land) 

ALTERNATE 

Country  -  16-bit  eniuneration 

225  (USA) 

64 

ENTITY 

Category  -  8-bit  enumeration 

4  (Self-prop  artillery) 

TYPE 

Subcategory  -  8-bit  enumeration 

1  (MLRS) 

Specific  -  8-bit  enumeration 

0  (unused) 

Extra  -  8-bit  enumeration 

0  (unused) 

X-Component  -  64-bit  floating  point 

assigned  by  application 

192 

ENTITY  LOCATION 

Y-Component  -  64-bit  floating  point 

assigned  by  application 

Z-Component  -  64-bit  floating  point 

assigned  by  application 

ENTITY 

X-Component  -  32-bit  floating  point 

0  (not  moving) 

96 

LINEAR 

Y-Component  -  32-bit  floating  point 

0  (not  moving) 

VELOCITY 

Z-Component  -  32-bit  floating  point 

0  (not  moving) 
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ENTITY  STATE  PDU  FIELDS  (cont) 


Psi  -  32-bit  floating  point 


Theta  -  32-bit  floating  point 


Phi  -  32-bit  floating  point 


32-bit  record  of  enumerations 


Bit  0  -  Paint  Scheme 


Bit  1  -  Mobility  Kill 


Bit  2  -  Fire  Power  Kill 


Bits  3-4  -  Damage 


RECKONING 

PARAMETERS 


MARKING 


CAPABILITIES 


Bits  7-8  -  Trailing  Effects  _ 


Bits  9-11  -  Hatch 


Bits  12-14  -  Lights _ 


Bit  15  -  Flaming  _ 


Bit  16  -  Launcher 


Bits  17-18  -  Camouflage  Type  _ 


Bit  19  -  Concealment 


Bits  20-23 


Bits  24-31  -  Entity  Specific 


Dead  Reckoning  Algorithm  -  8  bit  enumeration 


Other  Parameters  -  120  bits  unused 


Entity  Linear  Acceleration  -  3x32-bit  floating 

points  _ 


Entity  Angular  Velocity  -  3x32-bit  floating  points 


Character  set  -  8-bit  enumeration 


1 1  -  8-bit  unsigned  integers 


32  Boolean  Fields 


FIELD 

VALUE 


assigned  by  application 


assigned  by  application 


assigned  by  application 


1  (camouflage) 


0  (no  mobility  kill) 


0  (No  fire  power  kill) 


0  (no  damage) 
or 

3  (destroyed-  -if  det 
PDU  received  for  location 


0  (not  smoking) 
or 

1  (smoke  plume  -  if 
smoke  part  of 
destroyed  appearance) 


0  (none) 


0  (not  applicable) 


0  (none) 


0  (none) 


1  (raised)  _ 


0  (Desert  camouflage) 


0  (not  concealed) _ 


0  (unused)  _ 


0  (unused) 


1  (static) 


0  (unused) 


0,0,0  (not  accelerating) 


0,0,0  (not  rotating) 


0  (imused)  _ 


11x0  (unused) 


32  X  0  (no  capabilities) 
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2.0  Fire  PDUs 


Fire  PDUs  shall  be  issued  by  the  MLRS/ATACMS  FCPT.  Fire  PDUs  may  also  be  issued  by 
CIMUL8  but  it  is  not  required  for  this  application  of  DIS. 

The  MLRS/ATACMS  FCPT  shall  issue  PDUs  of  the  following  format: 


BEistiSTSl 

FIRE  PDU  FIELDS 

FIELD 

VALUE 

Protocol  Version  -  8-bit  enumeration 

3  (Version  2.0.3) 

Exercise  ID  -  8-bit  unsigned  integer 

100 

PDU 

PDU  Type  -  8-bit  enumeration 

2  (Fire  PDU) 

96 

HEADER 

Padding  -  8  bits  unused 

0  (unused) 

Time  Stamp  -  32-bit  unsigned  integer 

Relative  timestamp 
assigned  by  application 

Length  -  16-bit  imsigned  integer 

96  (bytes) 

Padding  - 16  bits  unused 

0  (unused) 

FIRING 

Site  -  16-bit  unsigned  integer 

100 

48 

ENTITY 

Application  -  16-bit  unsigned  integer 

400  (MLRS  FCPT) 

ID 

Entity  -  16-bit  unsigned  integer 

1 

TARGET 

Site  -  16-bit  unsigned  integer 

0  (unknown) 

48 

ENTITY 

Application  -  16-bit  unsigned  integer 

0  (unknown) 

ID 

Entity  -  16-bit  unsigned  integer 

0  (unknown) 

MUNITION 

Site  -  16-bit  unsigned  integer 

100 

48 

ID 

Application  -  16-bit  unsigned  integer 

400  (MLRS  FCPT) 

Entity  -  16-bit  unsigned  integer 

Site  -  16-bit  unsigned  integer 

100 

48 

EVENT  ID 

Application  -  16-bit  unsigned  integer 

400  (MLRS  FCPT) 

Event  -  16-bit  unsigned  integer 

1 

(Begin  at  1  and 
increment  by  1) 

32 

PADDING 

32-bit  unsigned  integer 

0  (xmused) 

LOCATION 

X-Component  -  64-bit  floating  point 

assigned  by  application 

192 

IN  WORLD 

Y-Component  -  64-bit  floating  point 

assigned  by  application 

Z-Component  -  64-bit  floating  point 

assigned  by  application 
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■SI 

■aMananSl 

FIRE  PDU  FIELDS  (cont) 

FIELD 

VALUE 

128 

BURST 

DESCRIPTION 

Munition  -  64-bit  Entity  Type  Record 

Entity  Kind 

Domain 

Country 

Category 

Sub-Categoiy 

Specific 

Extra 

2  (Munition) 

8  (Battlefield  Support) 
225  (USA) 

2  (Ballistic) 

16  (227  mm  rocket) 

0  (unused) 

0  (unused) 

Warhead  -  16-bit  enumeration 

1500  (bomblets) 

Fuze  -  16-bit  enumeration 

2000  (timed) 

Quantity  -  16-bit  unsigned  integer 

1  (single  rocket  fired) 

Rate  16-bit  unsigned  integer 

0  (for  quantity  1) 

X-Component  -  32-bit  floating  point 

assigned  by  application 

96 

VELOCITY 

Y-Component  -  32-bit  floating  point 

assigned  by  application 

Z-Component  -  32-bit  floating  point 

assigned  by  application 

32 

RANGE 

32-bit  floating  point 

assigned  by  application 
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3.0  Detonation  PDU 


The  Detonation  PDU  shall  be  issued  by  the  MLRS/ATACMS  FCPT.  CIMUL8  may  also  issue 
the  Detonation  PDU  but  it  is  not  required  for  this  application. 

The  MLRS/ATACMS  FCPT  shall  issue  a  Detonation  PDU  in  the  following  format: 


wuiSBsm 

DETONATION  PDU  FIELDS 

FIELD 

VALUE 

Protocol  Version  -  8-bit  enumeration 

3  (Version  2.0.3) 

Exercise  ID  -  8-bit  unsigned  integer 

100 

PDU 

PDU  Type  -  8-bit  enumeration 

2  (Fire  PDU) 

96 

HEADER 

Padding  -  8  bits  unused 

0  (unused) 

Time  Stamp  -  32-bit  unsigned  integer 

Relative  timestamp 
assigned  by  application 

Length  -  16-bit  unsigned  integer 

104  (bytes) 

Padding  - 16  bits  unused 

0  (unused) 

FIRING 

Site  -  16-bit  unsigned  integer 

100 

48 

ENTITY 

Application  -  16-bit  unsigned  integer 

400  (MLRS  FCPT) 

ID 

Entity  -  16-bit  unsigned  integer 

1 

TARGET 

Site  -  16-bit  unsigned  integer 

0  (unknown) 

48 

ENTITY 

Application  -  16-bit  unsigned  integer 

0  (unknown) 

ID 

Entity  -  16-bit  unsigned  integer 

0  (unknovm) 

MUNITION 

Site  -  16-bit  unsigned  integer 

100 

48 

ID 

Application  -  16-bit  unsigned  integer 

400  (MLRS  FCPT) 

Entity  -  16-bit  unsigned  integer 

100 

(Begin  at  100  and 
increment  by  1.  Should 
correlate  with  ES  PDUs 
for  munition  entity  if 
applicable) 

Site  -  16-bit  unsigned  integer 

100 

48 

EVENT  ID 

Application  -  16-bit  imsigned  integer 

400  (MLRS  FCPT) 

Event  -  16-bit  unsigned  integer 

1  (Begin  at  1  and 
increment  by  1) 

96 

VELOCITY 

X-Component  -  32  bit  floating  point 

assigned  by  application 

Y-Component  -  32  bit  floating  point 

assigned  by  application 

Z-Component  -  32  bit  floating  point 

assigned  by  application 
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HtsjMjl 

laBisKifnSl 

DETONATION  PDU  FIELDS  (cont) 

FELD 

VALUE 

■■■■ 

X-Component  -  64-bit  floating  point 

assigned  by  application 

192 

LOCATION  IN 

Y-Component  -  64-bit  floating  point 

assigned  by  application 

WORLD 

Z-Component  -  64-bit  floating  point 

assigned  by  application 

Munition  -  64-bit  Entity  Type  Record 

1500  (bomblets) 

Warhead  -  16-bit  enumeration 

2000  (timed) 

128 

BURST 

Fuze  -  16-bit  enumeration 

1  (single  rocket  fired) 

DESCRIPTION 

Quantity  -  16-bit  unsigned  integer 

0  (for  quantity  1) 

Rate  -  16-bit  unsigned  integer 

1  (single  rocket) 

COORDINATES 

X-Component  -  32-bit  floating  point 

assigned  by  application 

96 

LOCATION  IN 
ENTITY 

Y-Component  -  32-bit  floating  point 

assigned  by  application 

DETONATION 

RESULT 


#OF 

ARTICULATION 

PARAMETERS 


PADDING 


Z-Comoonent  -  32-bit  floating  point 


8-bit  enumeration 


8-bit  unsigned  integer 


16  bits  unused 


4  (ground  proximate 
detonation) 


0  (articulated  parts  not 
used) 


4.0  Transmitter  PDU 


The  Transmitter  PDU  shall  be  issued  by  all  systems  on  the  network  that  are  issuing  TACFIRE 
messages.  All  Transmitter  PDU's  shall  be  issued  using  the  following  format: 


IHiSSH 

TRANSMITTER  PDU  FIELDS 

FIELD 

VALUE 

96 

PDU 

HEADER 

Protocol  Version  -  8-bit  enumeration 

Exercise  ID  -  8-bit  unsigned  integer 

100 

PDU  Type  -  8-bit  enumeration 

Padding  -  8  bits  xmused 

IHHOEBSSSHBI 

Time  Stamp  -  32-bit  unsigned  integer 

Relative  timestamp 
assigned  by  application 

Length  -  16-bit  unsigned  integer 

Padding  - 16  bits  unused 

48 

ENTITY  ID 

Site  -  16-bit  imsigned  integer 

100 

Application  -  16-bit  unsigned  integer 

Entity  -  16-bit  unsigned  integer 

1 

16 

RADIO  ID 

16-bit  unsigned  integer 

1 

64 

RADIO 

ENTITY 

TYPE 

Entity  Kind  -  8-bit  enumeration 

7  (radio) 

Domain  -  8-bit  enumeration 

IHEESSSSSHH 

Country  -  16-bit  enumeration 

Category  -  8-bit  enumeration 

Specific  -  8-bit  enumeration 

Extra  -  8-bit  enumeration 

0  (undefined) 

0  (undefined) 

8 

TRANSMIT 

STATE 

8-bit  enumeration 

1  (on  but  not 
transmitting  -  after 
Signal  PDU  issued) 
or 

2  (on  and  transmitting  - 
before  Signal  PDU 
issued) 

8 

INPUT  SOURCE 

8-bit  enumeration 

0  (other) 

16 

PADDING 

16  bits  unused 

192 

ANTENNA  LOCATION 

X-Component  -  64-bit  floating  point 

assigned  by  application 

Y-Component  -  64-bit  floating  point 

assigned  by  application 

Z-Component  -  64-bit  floating  point 

assigned  by  application 

TRANSMITTER  PDU  FIELDS 
(cont) 

FIELD 

VALUE 

96 

RELATIVE 

ANTENNA 

LOCATION 

X-Component  -  32-bit  floating  point 

0  (same  as  entity 
location) 

Y-Component  -  32-bit  floating  point 

0  (same  as  entity 
location) 

Z-Component  -  32-bit  floating  point 

0  (same  as  entity 
location) 

16 

ANTENNA  PATTERN 
TYPE 

16-bit  enumeration 

0  (Omni-directional) 

16 

ANTENNA 
PATTERN  LENGTH 

16-bit  unsigned  integer 

0  (no  data) 

64 

FREQUENCY 

64-bit  unsigned  integer 

32 

TRANSMIT 

FREQUENCY 

BANDWIDTH 

32-bit  floating  point 

32 

POWER 

32-bit  floating  point 

64 

MODULATION 

TYPE 

Spread  Spectrum  - 16  Boolean  Array 

16x0  (unused) 

Major  -  16-bit  enumeration 

IHBESSHHI 

Detail  -  16-bit  enumeration 

System  -  16-bit  enumeration 

0  (imused)  I 

16 

CRYPTO  SYSTEM 

16-bit  enumeration 

16 

CRYPTO  KEY  ID 

16-bit  unsigned  integer 

8 

LENGTH  OF 
MODULATION 
PARAMETERS 

8-bit  unsigned  integer 

0  (no  data) 
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5.0  Signal  PDU 


The  Signal  PDU  shall  be  issued  by  all  systems  on  the  network  that  are  issuing  TACFIRE 
messages.  All  Signal  PDU's  shall  be  issued  using  the  following  format: 


SIGNAL  PDU  FIELDS 

FIELD 

VALUE 

Protocol  Version  -  8-bit  enumeration 

3  (Version  2.0.3) 

Exercise  ID  -  8-bit  unsigned  integer 

100 

PDU 

PDU  Type  -  8-bit  enumeration 

96 

HEADER 

Padding  -  8  bits  unused 

Time  Stamp  -  32-bit  unsigned  integer 

Relative  timestamp 
assigned  by  application 

Length  -  16-bit  unsigned  integer 

32  +  length  of 
TACFIRE  msg  (bytes) 

Padding  - 16  bits  unused 

Site  -  16-bit  unsigned  integer 

100 

48 

ENTITY  ID 

Application  -  16-bit  unsigned  integer 

100  (FED) 

200  (FDS) 

300  (CIMUL8) 

400  (MLRS) 

Entity  -  16-bit  unsigned  integer 

1 

16 

RADIO  ID 

16-bit  unsigned  integer 

1 

16 

ENCODING  SCHEME 

16-bit  enumeration 

2  (Application  Specific 
data) 

16 

PADDING 

16  bits  unused 

32 

SAMPLE  RATE 

32-bit  integer 

16 

LENGTH 

16  bits  integer 

length  of  TACFIRE 
message  sent 

16 

SAMPLES 

16-bit  integer 

N 

DATA 

Array  of  8-bit  imsigned  integers 

TACFIRE  message 
entered  here 
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APPENDIX  E 

USER  GUIDE  FOR  INTERFACES-DATA  LOGGER 
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USER  GUIDE  FOR  INTERFACES-DATA  LOGGER 


1.0  TACFIRE  Message  Format 

The  various  components  of  the  integrated  network  exchange  command  and  control  information 
using  TACFIRE  message  formats.  The  Call  For  Fire  (CFF)  format  is  provided  to  guide 
preparation  of  correct  TACFIRE  message  by  offering  a  means  to  confirm  field  values  for  CFF 
messages.  Other  message  formats  will  be  provided  later  as  they  become  available. 


Field 

# 

Field  Description 

Field 

Size 

(char) 

Field  Value 

Comments 

1 

Fire  Mission  Data  Group  ID 

1 

d 

Represents  Fire  Mission  Data  Group  ID 

2 

Fire  Mission  Action  Code 

1 

B 

Standard  Fire  Mission 

3 

Target  Number 

6 

Two  characters  and  four  digits  definable 
by  the  observer 

4 

Fire  Mission  Control 

1 

B 

Fire  When  Ready 

5 

Report  Control  Code 

1 

<space> 

No  control  codes  used 

6 

Time  I  Hour 

2 

00-23 

User  defined  time  of  day  in  hours 

7 

Time  I  Minute 

2 

00-59 

User  defined  time  of  day  in  minutes 

8 

Time  I  Second 

2 

00-59 

User  defined  time  of  day  in  seconds 

9 

Time  II  Hour 

2 

00-23 

User  defined  time  of  day  in  hours 

10 

Time  II  Minute 

2 

00-59 

User  defined  time  of  day  in  minutes 

11 

Time  II  Seconds 

2 

00-59 

User  defined  time  of  day  in  seconds 

12 

Observer  Identification 

2 

OA 

(0-9,  A-Z, 
space) 

ID  of  Observer 

13 

Fire  Mission  Warhead  Data  Group  ID 

1 

e 

Fire  Mission  Warhead  Data  Group  ID 

14 

Warhead  Type 

1 

A 

Rocket  High  Explosive  -  M77 

15 

Number  of  Rounds 

2 

01 

1  roimd  fired 

16 

Mission  Fired  Report  Suppression 

1 

B 

Transmit  Short  Mission  Fired 

17 

AT  II  Code 

1 

<space> 

Not  specified  for  this  case 

18 

Sheaf  Type 

1 

<space>  (A- 
Z,  <space>) 

Value  defined  by  manufacturer 

19 

Sheaf  Orientation 

3 

<3  spaces> 
(000-639,  or 

3  spaces) 

Represents  azimuth  in  tens  of  mils  or 
spaces  represent  blank  parking  heading 
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Field 

# 


— 

21 


— 

— 

— 

— 

26 


Z7 

28 


Field  Description 


Target  Count  Code 

THM  Target  Element  Separation 

Distance _ 

Clutter  Code 
Clutter  Code 
THM  Signature  Code 
THM  Flight,  Altitude 

Terminal  Homing  Munitions 
Scan  Limits 

Target  Area  Low  Level  MET  ID 
Time  Between  Rounds 


Field 

Size 

(char) 

1 

2 


2 

2 

2 

2 

3 


2 

2 


Field  Value 


<space> 

<2  spaces> 


<3  spaces> 
<3  spaces> 
<2  spaces> 
<3  spaces> 
<3  spaces> 


<2  spaces> 
05-99 


29 

30 

31 

32 

33 

34 

35 

35.1 

35.2 

35.3 

35.4 


Quadrant  Elevation  Option 
Target  Data  Group  ID 
Target,  UTM  1-Meter  Easting 
Target,  UTM  1-Meter  Norfliing 
Target,  Altitude 
Target,  Grid  Zone  Designator 
Number  of  Aimpoints 
Aimpoint  Easting  Shift 
Aimpoint  Northing  Shift 
Aimpoint  Altitude 
Aimpoint,  Rounds 


2 

2 

2 

2 

2 

2 

2 

2 

4 

2 

2 


1 

f 

0-999999 
0-11000000 
-9999  to  +9999 
+1  to  +60 
01  -  12 
-999  to  +999 
-999  to  +999 
-999  to  +999 

01 (00-99) 

(0-9,  A-Z, 


space) 


36 


Location  /data  Group  Identifier 


37 


Firing  Point  Location  Type 


38 


Coordinate  Identifier 


A1 
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Comments 


Not  specified  for  this  case _ 

Not  specified  for  this  case 

Not  specified  for  this  case _ 

Not  specified  for  this  case _ 

Not  specified  for  this  case _ 

Not  specified  for  this  case _ 

Not  specified  for  this  case 

Not  specified  for  this  case _ 

Time  between  rounds  for  suppression  of  fire 

Do  not  use  high  quadrant  elevation 

Target  Data  Group  ID _ 

UTM  grid  reference  for  easting  in  meters 
UTM  grid  reference  for  northing  in  meters 

Altitude  of  target  in  meters _ 

Northern  Hemisphere  Grid  Zones 

Number  of  aimpoints _ 

Aimpoint  Easting  shift  in  tens  of  meters 
Aimpoint  Northing  shift  in  tens  of  meters 
Aimpoint  altitude  in  one  meter  increments 

Number  of  rounds  to  fire  at  an  aimpoint  or 
spaces  represent  no  statement 

Location  data  group  identifier _ 

Type  of  location  for  a  firing  point.  In  this 

case.  Firing  Point _ 

Uniquely  identifies  a  particular  firing  point 
coordinate.  For  this  case  we  will  use  A1 . 


Field 

# 


Field  Description 


IBSiSH 


39  I  Firing  Point  Data  Action  Code  1 


40  Firing  Point,  Easting _ |  6 


41  I  Firing  Point,  Northing _ 8 


42  [  Firing  Point,  Altitude _ |  5 


43  I  Firing  Point,  Grid  Zone  _ |  3 


44  \  Parking  Heading  3 


45  3 

Masking  Azimuth,  Left 


46  I  Masking  Azimuth,  Right  3 


47  Masking  Elevation 

48  Range  to  Mask 


49  Submunition  Moving  Target  1 

Data  Group  Identifier _ 


50  I  Sighting  Hour  2 


51  I  Sighting  Minute  2 


52  I  Sighting  Second  2 


53  I  Speed,  Moving  Target _ |  2 


54  Direction  of  Movement  3 


55  Command  Data  Group  Identifier  J  1 


56  I  Command  Type  1 


Field  Value 


Comments 


A 

Firing  point  type  action  codes,  in  this  case, 
FIFO 

0-999999 

Easting  in  1  meter  increments 

0-11000000 

Northing  in  1  meter  increments 

-9999  to  +9999 

Firing  point  altitude  in  1  meter  increments 

+01  to  +60 

Grid  zone  in  Northern  Hemisphere 

<3  spaces> 
(000-639) 

Direction  from  Grid  North.  We  are  using  a 
blank  parking  heading 

<3  spaces> 
(000-639) 

Left  edge  of  the  mask,  direction  from  grid 
north.  We  are  not  specifying 

<3  spaces> 
(000-639) 

Right  edge  of  the  mask,  direction  fi'om  grid 
north.  We  are  not  specifying 

<4  spaces> 
(0000-1600) 

Elevation  fi*om  the  weapon  to  the  highest 
point  of  the  mask  in  one  mil  increments. 

We  are  not  specifying 

<4  spaces> 
(0-9999) 

Range  in  meters  to  the  center  of  the  mask. 
We  are  not  specifying 

t 

Submunition  moving  target  data  group  ID 

00-23 

Hour  of  the  day  when  a  target's  movement 
is  measured 

00-59 

Minutes  of  the  hour  when  a  target's 
movement  is  measured 

00-59 

The  second  of  a  minute  when  a  target's 
movement  is  measured 

00-99 

Speed  of  moving  target  in  km/hr 

000  -  639 

Direction  a  target  is  moving  in  tens  of  mils 

h 

Command  Data  Group  Identifier 

G 

Tactical  command  data  to  instruct 
launcher  to  move  to  designated  points, 
stay,  go  cool  or  go  hot.  In  this  case  we 
will  use  STAY 
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Field 

# 

Field  Description 

57 

Reload  Command  Indicator  I 

58 

Warhead  Type  I 

59 

Number  of  Rounds  for  LP/Cl 

60 

Reload  Command  Indicator  II 

61 

Warhead  Type  II 

62 

Number  of  Rounds  for  LP/C2 

63 

Effective  Hour 

64 

Effective  Minute 

65 

Effective  Second 

66 

Parking  Heading 

67 

Location  Data  Group  Identifier 

68 

Location  Type 

69 

Coordinate  Identifier 

70 

Data  Action  Code 

71 

Coordinate  Location  UTM  1  Meter 
Easting 

72 

Coordinate  Location  UTM  1  Meter 
Northing 

73 

Coordinate  Location  Altitude 

74 

Coordinate  Location  Grid  Zone 

75 

Park  Heading 

76 

Masking  Azimuth,  Left 

Field  Value 


<space> 


<2  spaces> 
(000-639) 


00-23 


000-639  or 
spaces 


0-999999 


0-11000000 


-9999  to  +9999 


+01  to  +60 


<3  spaces> 
(000-639  or 
spaces) 


Indicates  the  coded  reload  command  for 
LP/Cl.  We  will  use  the  command  "No 
change". 


None  specified 


None  specified 


Indicates  the  coded  reload  command  for 
LP/C2.  We  will  use  the  command  "No 
change". 


None  specified 


None  specified 


Effective  hour  of  event  or  report  in  units 
ofhours 


Effective  minute  of  event  or  report  in 
units  of  minutes 


Effective  second  of  event  or  report  in 
units  of  seconds 


Direction  fi*om  grid  north  in  tens  of  mils 
or  spaces  representing  blank  parking 
heading 


Location  data  group  identifier 


Indicates  the  type  of  launcher  location. 
For  our  use  -  Firing  Point 


Uniquely  identifies  a  particular  firing 
point  coordinate.  For  this  case  we  will 
use  Al. 


FIFO 


Easting  coordinate  in  meters 


Northing  coordinate  in  meters 


Coordinate  altitude 


Grid  zone  in  Northern  Hemisphere 


Direction  from  grid  north  in  tens  of  mils 
or  spaces  representing  blank  parking 
heading 


Left  edge  of  the  mask,  direction  from  grid 
north.  In  tens  of  mils  or  spaces 
indicating  blank  parking  heading 
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Field 

# 

Field  Description 

Field  Value 

Comments 

77 

Masking  Azimuth,  Right 

3 

Right  edge  of  the  mask,  direction  from  grid 
north.  In  tens  of  mils  or  spaces  indicating 
blank  parking  heading 

78 

Masking  Elevation 

4 

<4  spaces> 
(0000  to  1600) 

Elevation  from  the  weapon  to  the  highest 
point  of  the  mask  in  one  mil  increments 

79 

Range  to  Mask 

4 

<4  spaces> 
(0-9999) 

Range  in  meters  to  the  center  of  the  mask 

TOTAL  #  CHARACTERS 

215 
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NO.  OF 

NO.  OF 

1 

DIRECTORATE  FOR  MANPRINT 

ATTN  HQDA(DAPEMR) 

DEPUTY  CHIEF  OF  STAFF  PERSONNEL 

300  ARMY  PENTAGON 

WASHINGTON  DC  20310-0300 

1 

COMMANDER 

US  ARMY  MATERIEL  COMMAND 

ATTN  AMCAM 

5001  EISENHOWER  AVENUE 

ALEXANDRIA  VA  22333-0001 

1 

1 

DIRECTOR 

ARMY  AUDIOLOGY  &  SPEECH  CENTER 
WALTER  REED  ARMY  MEDICAL  CENTER 
WASHINGTON  DC  20307-5001 

OUSD(A)/DDDR&E(R&A)/E&LS 

1 

COMMANDER 

USA  OPERATIONAL  T&E 

AGENCY  ATTN  CSTE  TSM 

4501  FORD  AVENUE 

ALEXANDRIA  VA  22302-1458 

PENTAGON  ROOM3D129 

WASHINGTON  DC  20301-3080 

1 

USA  BIOMEDICAL  RSCH  &  DEV  LAB 

ATTN  LIBRARY 

FORT  DETRICK  BUILDING  568 

1 

CODE  1142PS 

OFFICE  OF  NAVAL  RESEARCH 

FREDERICK  MD  21702-5010 

1 

800  N  QUINCY  STREET 

ARLINGTON  VA  22217-5000 

WALTER  REED  ARMY  INST  OF  RESEARCH 

1 

HQ  USAMRDC 

ATTN  SGRDPLC 

FORT  DETRICK  MD  21701 

ATTNSGRDUWIC  (COL  REDMOND) 
WASHINGTON  DC  20307-5100 

1 

COMMANDER 

USA  AEROMEDICAL  RESEARCH  LAB 

ATTN  LIBRARY 

1 

DR  ARTHUR  RUBIN 

NATL  INST  OF  STANDARDS  &  TECH 

FORT  RUCKER  AL  36362-5292 

1 

BUILDING  226  ROOM  A3 13 

GAITHERSBURG  MD  20899 

COMMANDER 

1 

US  ARMY  SAFETY  CENTER 

ATTN  CSSC  SE 

FORT  RUCKER  AL  36362 

1 

US  ARMY  RESEARCH  INSTITUTE 

ATTN  PERI  ZT  (DR  EDGAR  M  JOHNSON) 
5001  EISENHOWER  AVENUE 

ALEXANDRIA  VA  22333-5600 

DEFENSE  LOGISTICS  STUDIES 

1 

CHIEF 

ARMY  RESEARCH  INSTITUTE 

AVIATION  R&D  ACTIVITY 

ATTN  PERIIR 

FORT  RUCKER  AL  36362-5354 

1 

INFORMATION  EXCHANGE 

US  ARMY  LOG  MGMT  COLLEGE 

FORT  LEE  VA  23801-6034 

DEPUTY  COMMANDING  GENERAL 

2 

D IRECTOR 

US  ARMY  RESEARCH  LABORATORY 

ATTN  AMSRL  OP  SD  TL  (TECH  LIB) 
ADELPHI  MD  20783-1145 

ATTN  EXS(Q) 

MARINE  CORPS  RD&A  COMMAND 
QUANTICO  VA  22134 

1 

TECHNICAL  INFORMATION  CENTER 

HQS  TRADOC  TEST  &  EXPERIMENTATION 
COMMAND  EXPERIMENTATION  CENTER 
BLDG  2925 

1 

HEADQUARTERS  USATRADOC 

ATTN  ATCDSP 

FORTORD  CA  93941-7000 

FORT  MONROE  VA  23651 

1 

US  ARMY  NATICK  RD&E  CENTER 

ATTN  STRNCYBA 

1 

COMMANDER 

USATRADOC 

COMMAND  SAFETY  OFFICE 

ATTN  ATOS  (MR  PESSAGNO  MR  LYNE) 
FORT  MONROE  VA  23651-5000 

NATICK  MA  01760-5020 
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NO.  OF 

COPIES  ORGANIZATION 


NO.  OF 

COPIES  ORGANIZATION 


1  US  ARMY  TROOP  SUPPORT  COMMAND 
NATICK  RD&E  CENTER 
ATTN  BEHAVIORAL  SCIENCES  DIV  SSD 
NATICK  MA  01760-5020 

1  US  ARMY  TROOP  SUPPORT  COMMAND 
NATICK  RESEARCH  DEVELOPMENT  AND 
ENGINEERING  CENTER 
ATTN  TECH  LIBRARY  (STRNC  MIL) 
NATICK  MA  01760-5040 

1  HQ  USA  RESEARCH  INST  OF 

ENVIRONMENTAL  MEDICINE 
ATTN  MEDRICL(DRJKOBRICK) 
NATICK  MA  01760-5007 

1  DR  RICHARD  JOHNSON 

HEALTH  &  PERFORMANCE  DIVISION 
US  ARIEM 

NATICK  MA  01760-5007 

1  LOCKHEED  SANDERS  INC 

BOX  MER-24-1583 
NASHUA  NH  03061-0868 

1  ATTN  DR  F  WESLEY  BAUMGARDNER 

USAF  ARMSTRONG  LABORATORY/CFTO 
SUSTAINED  OPERATIONS  BRANCH 
BROOKS  AFB  TX  78235-5000 

1  AFHRL/PRTS 

BROOKS  AFB  TX  78235-5601 

1  DRJONFALLESEN 

ARI  FIELD  UNIT 
PO  BOX  3407 

FORT  LEAVENWORTH  KS  66027-0347 

1  COMMANDER 

USAMC  LOGISTICS  SUPPORT  ACTIVITY 
ATTN  AMXT  S  AF 

REDSTONE  ARSENAL  AL  35898-7466 

1  ARI  FIELD  UNIT  FORT  KNOX 

BUILDING  2423  PERI  IK 
FORT  KNOX  KY  40121-5620 

1  COMMANDANT 

USA  ARTE.LERY  &  MISSILE  SCHOOL 
ATTN  USAAMS  TECH  LIBRARY 
FORT  SILL  OK  73503 


1  COMMANDER 

WHITE  SANDS  MISSILE  RANGE 

ATTN  STEWS  TE  RE 

WHITE  SANDS  MISSILE  RANGE  NM  88002 

1  COMMANDER 

WHITE  SANDS  MISSILE  RANGE 

ATTN  TECHNICAL  LIBRARY 

WHITE  SANDS  MISSILE  RANGE  NM  88002 

1  USA  TRADOC  ANALYSIS  COMMAND 

ATTN  ATRC  WSR  (D  ANGUIANO) 

WHITE  SANDS  MISSILE  RANGE  NM 

88002-5502 

1  STRICOM 

12350  RESEARCH  PARKWAY 
ORLANDO  FL  32826-3276 

1  COMMANDER 

USA  TANK-AUTOMOTIVE  R&D  CENTER 
ATTN  AMSTA  RS/D  REES 
WARREN  MI  48090 

1  COMMANDER 

USA  TANK-AUTOMOTIVE  R&D  CENTER 
ATTN  AMSTA  TSL  (TECH  LIBRARY) 
WARREN  MI  48397-5000 

1  COMMANDER 

USA  COLD  REGIONS  TEST  CENTER 
ATTN  STECR  TS  A 
APO  AP  96508-7850 

1  MR.  JOHN  HUNT 
GE  BLDG  148-301 
ROUTE  38 

MOORESTOWN  NJ  08057 

2  ADMINISTRATOR 

DEFENSE  TECHNICAL  INFORMATION 
CENTER  ATTN  DTIC  DDA 
8725  JOHN  J  KINGMAN  RD  STE  0944 
FTBELVOIR  VA  22060-6218 

1  US  ARMY  RSCH  DEV  STDZN  GP-UK 

ATTN  DR  MIKE  STOUT 
PSC  802  BOX  15 
FPOAE  09499-1500 

1  INSTITUTE  FOR  DEFENSE  ANALYSES 

ATTN  DR  JESSE  ORLANSKY 
1801  N  BEAUREGARD  STREET 
ALEXANDRIA  VA  22311 
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NO.  OF 

COPIES  ORGANIZATION 


NO.  OF 

COPIES  ORGANIZATION 


1  DR  RICHARD  W  PEW 

BBN  SYSTEMS  AND  TECHNOLOGY  CORP 
10  MOULTON  STREET 
CAMBRIDGE  MA  02138 

1  DR  NANCY  ANDERSON 

DEPARTMENT  OF  PSYCHOLOGY  1 

UNIVERSITY  OF  MARYLAND 
COLLEGE  PARK  MD  20742 

1  MR  LARRY  W  AVERY 

BATTELLE  PACIFIC  NW  LABS 

PO  BOX  999  MAIL  STOP  K6-66  1 

RICHLAND  WA  99352 

1  LIBRARY 

ESSEX  CORPORATION 

SUITE  510  1 

1430  SPRING  HILL  ROAD 
MCLEAN  VA  22102-3000 

1  DR  BEN  B  MORGAN 

DEPARTMENT  OF  PSYCHOLOGY  1 

UNIVERSITY  OF  CENTRAL  FLORIDA 
PO  BOX  25000 
ORLANDO  FL  32816 

1 

1  AFHRL/CA 

BROOKS  AFB  TX  78235 

1  DR  ARTHUR  S  KAMLET 

BELL  LABORATORIES 

6200  EAST  BROAD  STREET  1 

COLUMBUS  OH  43213 

1  MR  AJ  ARNOLD  STAFF  PROJECT  ENG 

HUMAN  FACTORS  DEPARTMENT 
GENERAL  MOTORS  SYSTEMS  ENGINEERING! 
1151  CROOKS  ROAD 
TROY  MI  48084 

1  DRLLOYDAAVANT 

DEPARTMENT  OF  PSYCHOLOGY  1 

IOWA  STATE  UNIVERSITY 
AMES  lA  50010 

1  DR  PAUL  R  MCCRIGHT 

INDUSTRIAL  ENGINEERING  DEPARTMENT  1 
KANSAS  STATE  UNIVERSITY 
MANHATTA  KS  66502 

1  DRMMAYOUB  DIRECTOR 

INSTITUTE  FOR  ERGONOMICS  RESEARCH 
TEXAS  TECH  UNIVERSITY 
LUBBOCK  TX  79409 


1  DR  TOM  MALONE 

CARLOW  ASSOCIATES  INC 
SUITE  750 

3141  FAIRVIEW  PARK  DRIVE 
FAIRFAX  VA  22042 

DR  NORMAN  B  ADLER 
DEPARTMENT  OF  COMPUTER 
AND  INFORMATION  SCIENCE 
UNIVERSITY  OF  PENNSYLVANIA 
PHILADELPHIA  PA  19104-6389 

COMMANDER 

US  ARMY  RESEARCH  INSTITUTE 
OF  ENVIRONMENTAL  MEDICINE 
NATICK  MA  01760-5007 

DR  DANIEL  J  POND 
BATTELLE  PNL/K6-66 
PO  BOX  999 
RICHLAND  WA  99350 

HQDA  (DAPE-ZXO) 

ATTN  DRFISCHL 
WASHINGTON  DC  20310-0300 

HUMAN  FACTORS  ENG  PROGRAM 
DEPT  OF  BIOMEDICAL  ENGINEERING 
COLLEGE  OF  ENG  &  COMPUTER  SCIENCE 
WRIGHT  STATE  UNIVERSITY 
DAYTON  OH  45435 

COMMANDER 

USA  MEDICAL  R&D  COMMAND 
ATTN  SGRD  PLC  (LTC  JJ  JAEGAR) 

FORT  DETRICK  MD  21701-5012 

PEO  ARMAMENTS 
ATTN  AMCPEO  AR 
BUILDING  171 

PICATINNY  ARSENAL  NJ  07806-5000 

PEO  AIR  DEFENSE 
ATTN  SFAEADS 
US  ARMY  MISSILE  COMMAND 
REDSTONE  ARSENAL  AL  35898-5750 

JON  TATRO 

HUMAN  FACTORS  SYSTEM  DESIGN 
BELL  HELICOPTER  TEXTRON  INC 
PO  BOX  482  MAIL  STOP  6 
FT  WORTH  TX  76101 
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NO.  OF  NO.  OF 

COPIES  ORGANIZATION  COPIES 

1  DAVID  ALDEN  1 

HUGHES  SIMULATION  SYSTEMS  INC 
5301  E  RIVER  RD 
MINNEAPOLIS  MN  55421-1024 

1  OASD  (FM&P)  1 

WASHINGTON  DC  20301-4000 


1  COMMANDER 

US  ARMY  MATERIEL  COMMAND 
ATTN  AMCDEAQ 

500 1  EISENHOWER  AVENUE  1 

ALEXANDRIA  VA  22333 

1  COMMANDER 

MARINE  CORPS  SYSTEMS  COMMAND 
ATTN  CBGT  1 

QUANnCO  VA  22134-5080 

1  DIRECTOR  AMC-FIELD  ASSISTANCE 

IN  SCIENCE  &  TECHNOLOGY 
ATTN  AMC-FAST  (RICHARD  FRANSEEN) 
FTBELVOIR  VA  22060-5606 

1  COMMANDER 

US  ARMY  FORCES  COMMAND 
ATTN  FCDJSA  BLDG  600 
AMC  FAST  SCIENCE  ADVISER 
FT  MCPHERSON  GA  30330-6000 

1  COMMANDER 

I  CORPS  AND  FORT  LEWIS 
AMC  FAST  SCIENCE  ADVISER 
ATTN  AFZHCSS 
FORT  LEWIS  WA  98433-5000 

1  HQ  m  CORPS  &  FORT  HOOD 

OFFICE  OF  THE  SCIENCE  ADVISER 
ATTN  AFZFCSSA 
FORT  HOOD  TX  76544-5056 

1  COMMANDER 

U.S.  ARMY  NATIONAL  TRAINING  CENTER 
AMC  FAST  SCIENCE  ADVISER 
ATTN  AMXLASA 
FORT  IRWIN  CA  92310 

1  COMMANDER 

HQ  XVm  ABN  CORPS  &  FORT  BRAGG 
OFFICE  OF  THE  SCI  ADV  BLDG  1-1621 
ATTN  AFZAGDFAST 
FORT  BRAGG  NC  28307-5000 


ORGANIZATION 

SOUTHCOM  WASHINGTON  FIELD  OFC 
1919  SOUTH  EADS  ST  SUITE  L09 
AMC  FAST  SCIENCE  ADVISER 
ARLINGTON  VA  22202 

HQ  US  SPECIAL  OPERATIONS  COMMAND 
AMC  FAST  SCIENCE  ADVISER 
ATTN  SOSD 

MACDILL  AIR  FORCE  BASE 
TAMPA  FL  33608-0442 

HQ  US  ARMY  EUROPE  AND  7TH  ARMY 
ATTN  AEAGXSA 
OFFICE  OF  THE  SCIENCE  ADVISER 
APOAE  09014 

COMMANDER 

HQ  2 1ST  THEATER  ARMY  AREA  COMMAND 
AMC  FAST  SCIENCE  ADVISER 
ATTN  AERSA 
APOAE  09263 

1  COMMANDER 

HEADQUARTERS  USEUCOM 
AMC  FAST  SCIENCE  ADVISER 
UNIT  30400  BOX  138 
APOAE  09128 

1  HQ  V  CORPS 

COMMAND  GROUP  UNIT  #25202 
AMC  FAST  SCIENCE  ADVISER 
ATTN  AETVSA 
APOAE  09079-0700 

1  HQ  7TH  ARMY  TRAINING  COMMAND 

UNIT  #28130 

AMC  FAST  SCIENCE  ADVISER 
ATTN  AETTSA 
APOAE  09114 

1  COMMANDER 

HHC  SOUTHERN  EUROPEAN  TASK  FORCE 
ATTN  AESESA  BUILDING  98 
AMC  FAST  SCIENCE  ADVISER 
APOAE  09630 

1  COMMANDER 

US  ARMY  PACIFIC 

AMC  FAST  SCIENCE  ADVISER 

ATTN  APSA 

FT  SHATTER  HI  96858-5L00 


86 


NO.  OF 

COPIES  ORGANIZATION 


NO.  OF 

COPIES  ORGANIZATION 


I  COMMANDER 

US  ARMY  JAPAN/DC  CORPS 
UNIT  45005  ATTN  APAJ  SA 
AMC  FAST  SCIENCE  ADVISERS 
APOAP  96343-0054 

1  AMC  FAST  SCIENCE  ADVISERS 

PCS  #303  BOX  45  CS-SO 
APOAP  96204-0045 

1  COMMANDER  ALASKAN  COMMAND 

ATTN  SCIENCE  ADVISOR  (MR  GRILLS) 
6-900  9TH  ST  STE  110 
ELMENDORFAFB  ALASKA  99506 

1  CDR  &  DIR  USAE  WATERWAYS 

EXPERIMENTAL  STA 
ATTN  CEWES  IM  MI  R  (AS  CLARK 
CD  DEPT  #1153) 

3909  HALLS  FERRY  ROAD 
VICKSBURG  MS  39180-6199 

1  DIRECTOR 

US  ARMY  RESEARCH  LABORATORY 
ATTN  AMSRL  OP  SD  TP  (TECH  PUB) 
ADELPHI  MD  20783-1145 

1  DIRECTOR 

US  ARMY  RESEARCH  LABORATORY 
ATTN  AMSRL  OP  SD  TA  (REC  MGMT) 
ADELPHI  MD  20783-1145 

1  DRSEHCHANGHAH 

DEPT  OF  BEHAVIORAL  SCIENCES  & 
LEADERSHIP 
BUILDING  601  ROOM  281 
US  MILITARY  ACADEMY 
WEST  POINT  NEW  YORK  10996-1784 

1  US  ARMY  RESEARCH  INSTITUTE 

ATTN  PERI  IK  (DOROTHY  FINLEY) 

2423  MORANDE  STREET 
FORT  KNOX  KY  40121-5620 

5  CHIEF  ARL  HRED  USAFAS  FIELD 

ELEMENT 

ATTN  AMSRL  HR  MF  (L  PIERCE) 

BLDG  3040  ROOM  220 
FORT  SILL  OK  73503-5600 

ABERDEEN  PROVING  GROUND 

5  US  ARMY  RESEARCH  LABORATORY 

ATTN  AMSRL  OP  AP  L  (TECH  LIB) 
BLDG  305 


1  ARL  LIBRARY 

BLDG  459 

1  ARL  SLAD 

ATTN  AMSRL  BS  (DR  JT  KLOPCIC) 
BLDG  328  APG-AA 

1  COMMANDER 

CHEMICAL  BIOLOGICAL  AND 
DEFENSE  COMMAND 
ATTN  AMSCBCI  APG-EA 

1  USATECOM 

RYAN  BUILDING 
APG-AA 
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